System and method for implementing safety instrumented systems in a fieldbus architecture

ABSTRACT

An apparatus, system and process is provided for communicating safety-related data, over an open system, from a sender to a receiver. Safety-related components, including function blocks, flexible function blocks, resource blocks and transducer blocks, as well as, safety-related objects are provided. Also, an extended safety-related protocol provides for authenticating communications between safety-related components over an existing black channel, such as one using a fieldbus Architecture.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation patent application of U.S. patentapplication Ser. No. 11/656,883 filed Jan. 22, 2007, which is acontinuation of U.S. patent application Ser. No. 11/240,939 filed Sep.30, 2005 and entitled “System and Method for Implementing SafetyInstrumented Systems in a Fieldbus Architecture”, now U.S. Pat. No.7,167,762, issued Jan. 23, 2007, which is a continuation 10/826,576,filed on Apr. 16, 2004 and entitled “System and Method for ImplementingSafety Instrumented Systems in a Fieldbus Architecture”, now U.S. Pat.No. 6,999,824, issued Feb. 14, 2004, which claims the benefit of U.S.provisional patent application No. 60/463,334, filed on Apr. 17, 2003and entitled “Safety Instrumented Systems Function Blocks”; and10/826,576 is a continuation-in-part of U.S. patent application Ser. No.10/453,596, filed Jun. 4, 2003 and entitled “Flexible Function Blocks”;which is a continuation-in-part of U.S. patent application Ser. No.10/160,094, filed Jun. 4, 2002 and entitled “Block-oriented ControlSystem”, now U.S. Pat. No. 6,594,530; which is a continuation of U.S.patent application Ser. No. 08/916,178, filed Aug. 21, 1997 and entitled“Block-oriented Control System”, now U.S. Pat. No. 6,424,872, issuedAug. 21, 1997. These applications and patents are each incorporated byreference herein.

The present application also incorporates by reference the disclosuresset forth, in their entirety, in the following patents and/or patentapplications:

-   -   U.S. Provisional Patent No. 60/024,346, entitled “A        Block-Oriented Control System,” filed Aug. 21, 1997;    -   U.S. patent application Ser. No. 09/598,697, entitled        “Block-Oriented Control System On High Speed Ethernet,” filed        Jun. 21, 2000;    -   U.S. Provisional Patent Application No. 60/139,814, entitled        “Foundation Fieldbus on HSE,” filed on Jun. 21, 1999;    -   U.S. Provisional Application No. 60/384,846, entitled “Flexible        Function Blocks,” filed Jun. 4, 2002; and    -   U.S. patent application Ser. No. 10/226,282, entitled        “Integrated Fieldbus Data Server Architecture,” filed Aug. 23,        2002.

TECHNICAL FIELD

The technical field, to which the various embodiments of the presentinvention relate, is control system architecture. More particularly, thetechnical field relates to systems and methods for controlling thefunctions and operation of safety instrumented systems in automaticcontrol systems. Even more particularly, certain embodiments of thepresent invention relate to systems and methods for controlling safetyinstrumented systems in the context of an automatic control system whichlinks device controllers via a control network to facilitatedecentralized control of industrial, manufacturing and other processes.

BACKGROUND

Industrial, manufacturing, petrochemical and other “automationindustries” implementing complex processes and systems have beenmigrating from proprietary, centralized architectures to open,decentralized architectures to facilitate automation of such processesand systems. Decentralized architectures commonly implement fieldbuscontrol systems and networks wherein control is distributed amongst thevarious devices within the network and/or system. Examples of open,interoperable and decentralized fieldbus architectures include theFOUNDATION™ fieldbus from the Fieldbus Foundation (Austin, Tex.),PROFIBUS from PROFIBUS International (Karlsruhe, Germany); LonWorks fromEchelon Corporation (San Jose, Calif.), industrial Ethernet and others(hereafter, collectively “fieldbus Architectures”).

The demand for open and interoperable, distributed control fieldbussystems is often driven by equipment suppliers and users. Supplierscommonly prefer fieldbus Architectures because it allows them to selltheir products and/or services to more users, instead of only to usersoperating a specific proprietary system. Users desire to utilizefieldbus Architectures, for example, because it often enables them toselect the fieldbus devices and/or services from multiple suppliersinstead of only devices specifically designed for a proprietary system.

Many sectors of the automation industry also have a need for special“safety” systems to ensure the safety of plant personnel and to preventdamage to equipment due to unexpected events. These special “safety”systems are collectively called “Safety Instrumented Systems” (SIS).Users and suppliers often require SIS systems to comply withinternational safety standards such as International ElectotechnicalCommittee (IEC) 61508 (functional safety ofelectrical/electronic/programmable electronic safety-related systems),and IEC 61511 (functional safety: safety instrumented systems for theprocess industry sector). Currently available SIS control solutions arecommonly proprietary and are not compatible with fieldbus Architectures.

Thus, users and suppliers of SIS devices and systems have a need for anopen, interoperable SIS fieldbus Architecture (hereafter, an “SISfieldbus”) that enable users to support and/or provide SIS control usingexisting fieldbus Architectures. Desirably, an SIS fieldbus is directlycompatible with existing fieldbus Architectures and do not requiremodification to existing communication protocols, function blocks and/orother network aspects.

SUMMARY

An apparatus for operating in a block-oriented safety related opencontrol system is provided by one embodiment of the present invention.Such apparatus comprises a memory, which includes at least one safetyrelated function block, a processor, operably connected to the memory,wherein the processor executes the safety related function block basedon a system schedule, and a medium attachment unit, which translatesinput messages and output messages between the processor and atransmission medium using an extended safety-related protocol. Inanother embodiment, the memory in the apparatus further includes asafety-related resource block, a first safety-related transducer block,and a second safety-related transducer block, wherein the resource blockinsulates the safety-related function block from physical hardware, thefirst safety-related transducer block decouples the input to thesafety-related function block, and the second safety-related transducerdecouples the output of the safety-related function block.

In another embodiment of the present invention, a system is provided forpermitting interoperability between safety and non-safety relateddevices in a block-oriented open control system. The system comprises aplurality of safety and non-safety related devices. At least one of thesafety related devices includes a safety-related resource block and asafety-related function block. Further, the safety-related resourceblock uniquely identifies a safety-related resource provided in thesafety related device and the safety-related function block processesparameters associated with the safety-related resource to produce anoutput message. The system also comprises a medium attachment unit whichis operably connected to at least the safety-related function block. Themedium attachment unit translates an input message from a transmissionmedium to the safety-related function block and the output message fromthe safety-related function block to the transmission medium using anextended safety-related protocol.

In another embodiment of the present invention, an apparatus is providedwhich enhances the interoperability of a block-oriented open controlsystem with safety related devices. The apparatus comprises a means forstoring at least one safety-related function block, which includescontained parameters and a computer program. The safety-related functionblock includes end-user configured parameters and an end-user configuredalgorithm. The apparatus also comprises a means, coupled to the storingmeans, for processing the safety-related function block using thecontained parameters. The processing of the contained parametersproduces an output parameter. The apparatus also includes a means,coupled to the processing means, for translating messages from theprocessor for transmission on a transmission medium using an extendedsafety-related protocol.

Another embodiment of the present invention provides an apparatus whichoperates in a block-oriented open control system that includes safetyrelated components. The apparatus comprises a user layer, which includesa safety-related function block to provide functionality. Thesafety-related function block includes end-user configured parametersand an end-user configured algorithm. The apparatus also comprises aphysical layer, which translates messages from a transmission mediuminto a suitable format for the user layer and from the user layer into asignal for transmission on the transmission medium using an extendedsafety-related protocol. A communications stack, connected to the userlayer and the physical layer, is also provided. The communications stackincludes a data link layer and an application layer. The data link layercontrols the transmission of messages onto the transmission medium andthe application layer allows the user layer to communicate over thetransmission medium.

In another embodiment of the present invention, a memory for storingdata for access by an application framework operating in a device withina block-oriented open control system with safety related components isprovided. The memory includes a data structure stored in the memory. Thedata structure further includes a safety-related function block, and asafety-related resource block. The safety-related resource block makeshardware specific characteristics of the device electronically readable.The memory also includes at least one safety-related transducer blockwhich controls access to the safety-related function block.

Another embodiment of the present invention includes a process forcommunicating safety related data from a publisher to a subscriber overan open control system. The process comprises obtaining informationuseful in generating a first data sequence, generating the first datasequence using the obtained information, generating a firstauthenticator for the first data sequence, generating a second datasequence, wherein the second data sequence includes the safety relateddata and the first authenticator, communicating the second data sequencefrom the publisher to the subscriber, generating a third data sequenceat the subscriber using at least one sequence of data received in thesecond data sequence, calculating a second authenticator at thesubscriber based upon the third data sequence, comparing the receivedfirst authenticator to the second authenticator, rejecting the seconddata sequence from further processing when the first authenticator andthe second authenticator are different, and accepting the second datasequence when the first authenticator and the second authenticator arethe same.

It is to be appreciated that other embodiments of the system, apparatus,articles of manufacture and processes of the present invention arefurther described and set forth herein with reference to the drawingfigures, the detailed description and the claims. Thus, the spirit andscope of the present invention should not be limited to the abovesummarized embodiments.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 is an overview of an extended control system which may beutilized in conjunction with one or more embodiments of the presentinvention to support an SIS fieldbus.

FIG. 2 shows the Open Systems Interconnect layered communication modelas compared to the communication model utilized in one embodiment of thepresent invention.

FIG. 3 illustrates a hardware embodiment of a field device.

FIG. 4 summarizes the virtual communication relationships provided bythe Fieldbus Access Sublayer.

FIG. 5 illustrates two devices interconnected via the communicationservices one with safety-related components and one withoutsafety-related components.

FIG. 6 illustrates an object dictionary.

FIGS. 7A and 7B illustrate the virtual communication devices within thecommunication model of the present invention for use in safety andnon-safety devices.

FIGS. 8A and 8B illustrate a function block application structure withina field device containing safety and non-safety related components.

FIGS. 9A and 9B illustrate external devices interconnected on a bus withfield devices for safety and non-safety implementations.

FIG. 10 illustrates the preferred layout of an object dictionarydirectory object.

FIG. 11 illustrates examples of parameters interconnected for a singleloop for safety and non-safety related components.

FIG. 12 illustrates one embodiment of a system architecture of thepresent invention.

FIG. 13 illustrates a safety-related function block with userconfigurable inputs, user configurable outputs, and a user configurablealgorithm.

FIG. 14 illustrates an application using standardized safety andnon-safety related function blocks and flexible function blocks for atleast one embodiment of the present invention.

FIG. 15 is a block diagram illustrating an example of an applicationusing standardized, flexible function blocks and FFBs.

FIGS. 16A, 16B and 16C are a flow diagram illustrating one methodologyby which data may be communicated, using a publisher-subscribertopology, and authenticated for safety-related function blocks andsafety-related flexible function blocks.

FIGS. 17A, 17B and 17C are a flow diagram illustrating one methodologyby which data may be communicated, using a client-server topology, andauthenticated for safety-related function blocks and safety-relatedflexible function blocks.

DETAILED DESCRIPTION

As described herein, the various embodiments of the present inventionprovide systems, components and methods (hereafter, collectively“systems”) for utilizing SIS devices in new and/or existing fieldbusArchitectures. Desirably, the various systems set forth herein may beutilized in various types and forms of SIS devices as well as in varioustypes of fieldbus Architectures. Further, the various systems of thepresent invention may desirably be utilized in various fieldbusArchitectures without significant, and preferably zero, changes to theprotocols, methodologies or other processes currently utilized infieldbus Architectures to communicate non-SIS information across thenetwork for notification to and/or utilization by network compatiblefieldbus devices.

More particularly, one embodiment of an SIS implementation may includean apparatus configured for operating in an open control system thatincludes: a memory, which includes system management data; one or moreSIS elements; a processor, operably connected to the memory; a mediumattachment unit, which translates input messages and output messagesbetween the processor and a transmission medium; and an extended safetyor safety-related protocol (“SISRP”), which provides the desired levelof security needed for a particular SIS implementation. The systemmanagement data may include system schedule information which theprocessor desirably executes as specified by the system schedule.

Another embodiment of the present invention may provide for an SISimplementation in a fieldbus Architecture by, for example, permittinginteroperability between a plurality of devices, at least one of whichincludes an SIS component (“SISC”), such as a resource block, a functionblock, a transducer block or a link object, and a medium attachmentunit, operably connected to the SISC. In such an embodiment, theresource blocks uniquely identify each device, the function blockprocesses parameters to produce an output message, and the mediumattachment unit translates input message(s) received, for example, froma transmission medium to the SIS device and output messages from the SISdevice to the transmission medium. Such an embodiment may be consideredto be a function block implementation.

Yet, other implementations may also be provided by and/or used inconjunction with the teachings of the present invention. In one suchembodiment of the present invention, an apparatus is provided whichdesirably includes: a user layer, that includes an encapsulated SISC toprovide functionality; a physical layer, which translates messages froma transmission medium into a suitable format for use by the user layerand from the user layer into a signal for transmission on thetransmission medium; and a communications stack, connected to the userlayer and the physical layer. The communication stack may include a datalink layer and an application layer. The data link layer controls thetransmission of messages onto the transmission medium. The applicationlayer allows the user layer to communicate over the transmission medium.

Another embodiment of the present invention may provide for an SISimplementation in a fieldbus Architecture by permitting interoperabilitybetween a plurality of devices, wherein at least one device includes aresource block, a link object, and a medium attachment unit, operablyconnected to the link object. In such an embodiment, the resource blocksuniquely identify each device, the link object receives processedparameters and produces an output message, and the medium attachmentunit translates an input message from a transmission medium to the linkobject and the output message from the link object to the transmissionmedium.

Yet, another embodiment of the present invention may include anapparatus that desirably includes: a user layer, which includes one ormore encapsulated SISC(s) to provide functionality; a physical layer,which translates messages from a transmission medium into a suitableformat for the user layer and from the user layer into a signal fortransmission on the transmission medium; and a communications stack,connected to the user layer and the physical layer. The communicationstack includes a data link layer and an application layer. The data linklayer controls the transmission of messages onto the transmissionmedium. The application layer allows the user layer to communicate overthe transmission medium.

Likewise, the foregoing and other embodiments of the present inventionmay include a memory for storing data for access by an applicationframework operating in a device within a control system. The memoryincludes a data structure stored in the memory, the data structureincluding one or more SISCs, such as a resource block, which makeshardware specific characteristics of the device electronically readable,an encapsulated function block, and at least one transducer block. Thefunction block includes end-user configured program and parameters andthe at least one transducer block controls access to the function block.

Thus, it is to be appreciated that the various embodiments of thepresent invention may be provided for in various forms of devices andsystems. Some of which utilize SISCs and/or an SISRP to incorporate SISdevices into existing fieldbus Architectures. For purpose of clarity andsimplicity, however, the various embodiments of the present inventionare hereinafter primarily described herein with reference to oneembodiment of a fieldbus Architecture, namely, one which utilizesfunction blocks to provide a general structure for specifying differenttypes of device functions while utilizing a common fieldbuscommunications network.

As is commonly known and appreciated, a function block implementation ofa fieldbus Architecture defines the internal components of anapplication, or portion thereof, implemented by a device to provide forsystem operation. Function block applications specify how eachapplication, or portion thereof, interfaces with each other applicationin the system so as to provide for standardized inter-operabilitybetween devices.

One implementation of a function block implementation of a fieldbusArchitecture has been specified as the FOUNDATION™ fieldbusspecifications as provided by the Fieldbus Foundation of Austin, Tex. Asis commonly known and appreciated, the FOUNDATION™fieldbus specifies alower speed fieldbus (H1) optimized for process control, and a HighSpeed Ethernet (HSE) fieldbus backbone for high performance control,subsystem integration, and management information systems integration.The control system can support a variety of field devices, includingsensors and actuators, or high speed field devices, such as cellcontrol, motors, drives and remote input/output (I/O). Since FOUNDATION™fieldbus is open and interoperable, distributed control architecture,control devices from by different vendors interoperate on the H1 or HSEfieldbus and share the control functions (e.g., control is distributedinto the fieldbus devices). Distribution of control into the fieldbusdevices often reduces system installation cost because the need forcentralized control computers and I/O subsystems are reduced oreliminated. Further, distribution of control into fieldbus devices oftenreduces system operating and maintenance costs because standard functionblocks in the devices provide more information about processmeasurements and device status. It is in this context, that oneembodiment of the present invention for providing for fieldbus controlof SIS devices is set forth herein. It is to be appreciated, however,that the present invention is not limited to below described FieldbusFoundation implementation and may be incorporated into other fieldbusArchitectures.

In particular, one embodiment of the present invention utilizes aFOUNDATION™ fieldbus Architecture to provide a new and improved controlsystem architecture with enhanced and additional communication security.Such communication security is provided in addition to and/or “above”the security provided by existing communication systems while utilizingnew, security related, function blocks which are compatible with anexisting function block framework, such as the framework provided in theFOUNDATION™ fieldbus specifications. It is to be appreciated that thenew system commonly eliminates and/or significantly reduces, the needfor expensive and difficult to maintain custom control software andspecial input/output “I/O” devices for SIS applications. Thesafety-related function blocks described herein, with reference to thisand similar embodiments, are collectively referred to herein as SafetyInstrumented System Functions Blocks (“SISFB”)—one embodiment of anSISC.

SISFB System Overview

As shown in FIG. 1, a field device (which may contain one or more SISCs)is one which operates on a fieldbus Architecture control system and isgenerally categorized as a non-SIS compatible link active scheduler 100,an SIS compatible link active scheduler 100′, a (non)-SIS compatiblelink master 105/105′, or a (non)-SIS compatible basic device 110/110′.As is discussed in greater detail below, SIS and non-SIS components inSIS devices (i.e., link active schedulers, link masters and basicdevices) are substantially similar, but, SIS components utilize anadditional extended safety or SISRP to ensure communications betweenSISCs are secure and have not been corrupted, modified or otherwisedegraded. Thus, when SIS devices are included in a fieldbus Architecturecontrol system, such SIS field devices may be further categorized as anSIS link active scheduler 100′, an SIS link master 105′, or an SIS basicdevice 110′. SISCs may communicate with other SISCs and/or non-SISCs(for example, for purposes of reporting and other uses) using existingfieldbus Architectures such as bus 120 and/or 120′.

Regardless of whether a field device includes an SISC, a field device iscategorized based upon its control capabilities and responsibilities.For example, a field device is categorized as a link active scheduler100/100′ if it is acting as network controller of a bus 120/120′. Afield device is categorized as a link master 105/105′ if it is capableof acting as the network controller or link active scheduler, but hasnot assumed that responsibility. A basic device 110/110′ is not capableof acting as the network controller.

The field devices are electronically coupled or connected by atransmission medium 120/120′, which can be individual input and outputwires or a variety of bus configurations. As shown in FIG. 1, theembodiment uses a bus configuration by which both field devices withSISCs and non-SISCs may be connected. The throughput rate of the bus mayvary. A few of exemplary buses are the 31.25 kbit/s H1 bus and the 100Mbit/s HSE bus. However, other bus data transfer rates andconfigurations may be suitably utilized in conjunction with the variousembodiments of the present invention. Bus data transfer rates aregenerally independent of whether SISC and/or non-SISC field devices areconnected to the control system. It is to be appreciated that thebridges 130 (FIG. 1) and buses 120/120′ may be suitably replaced byother system configurations. For example, one embodiment may utilize HSEdevices which are connected in a star topology by Ethernet switches.Other system and/or network embodiments may also be utilized.

In the presently described embodiment, however, the H1 bus is generallyused for process control applications, such as temperature, level, andflow control. The HSE bus is generally used for high speed applications.Devices operating on HSE buses are usually self-powered or draw powerfrom a separate power bus in the fieldbus cable (i.e., 4 wire cable),however, they can also be powered directly from the fieldbus.

In the embodiment shown in FIG. 1, there are several link master devices105/105′ operating on the bus(es) 120/120′. When these link masterdevices 105/105′ are activated, these (SIS) link master devices 105/105′bid for the responsibility of becoming the link active scheduler100/100′. In the embodiment shown, the link master device 105/105′ whichbecomes the link active scheduler 100/105′ is the device with the lowestnetwork address. In alternative embodiments, a particular device may bethe “preferred” link master. In which case, when the system is activatedthe link master 105/105′ with the lowest network address would assumethe responsibilities of the link active scheduler 100/100′. Then, the“preferred” link master 105/105′ would send a message to the link activescheduler 100/100′ directing it to transfer control. Upon receipt of themessage, the link active scheduler 100/100′ would transfer control tothe preferred link master 105/105′.

Further, when SIS devices are connected to the control system, forexample, on bus 120 or 120′, preferably the link master designated asthe link active scheduler is SIS compatible. As shown in FIG. 1, the bus120′ is suitably controlled by an SIS link active scheduler 100′ becauseof the existence of the SIS basic device 110′ on the network 120′. As isdiscussed in greater detail hereinbelow, SISCs in SIS field devices 110′are commonly configured to accept inputs and instructions from SISCs inother SIS devices and not from non-SISCs in SIS or non-SIS devices.Non-SISCs in SIS or non-SIS devices, however, commonly can accept inputsand instructions from SISC or non-SISC components. Thus, when SISCs areincluded in a network, desirably the designated link master schedulerinclude any necessary SISCs.

When multiple link masters 105/105′ exist on a bus 120/120′, there are avariety of ways to conduct the bidding process. For example, one type ofbidding process is shown in U.S. Pat. No. 5,526,358, issued Jun. 11,1996, which is hereby incorporated by reference in its entirety. Thebidding process may also be conducted if the link active scheduler100/100′ controlling a bus 120/120′ malfunctions or is removed. Yet,when SIS devices 105′ are on a bus, the link active scheduler should beselected from an available SIS link master 105′.

The control system can also include a bridge 130 to interconnectindividual buses and create larger networks. Communication between theindividual buses can be monitored by one or more operator stations 150.Further, in an SIS embodiment, the operator stations are desirably SIScompatible.

Further, in the present embodiment, a link master 105/105′ desirablycontains the same control capabilities as a link active scheduler100/100′. Thus, the capabilities of both are discussed further hereinwith reference to a link master. More particularly, a link master105/105′ incorporates a program interface comprising the following threelayers: (1) a physical layer, (2) a communications stack, and (3) a userlayer. When SISCs are utilized in field devices, the user layer furtherincludes and utilizes an SISRP or interface, as is discussed in greaterdetail hereinbelow. Otherwise, SIS and non-SIS compatible componentsutilize common physical layers, communications stacks and user layers.

As shown in FIG. 2, for one embodiment of the present invention, thephysical layer (PHY) 200 and the communications stack 205 are derivedfrom the Open Systems Interconnect (OSI) model. The physical layer (PHY)200 is desirably the same as OSI layer 1, and the communications stack205 generally corresponds to OSI layers 2 and 7. The user layer 235 isnot defined by the OSI model. In alternative embodiments, the physicallayer 200 and communications stack 205 may be derived from a variety ofdifferent networking standards, such as Transmission ControlProtocol/Internet Protocol (TCP/IP), UNIX and others. A detaileddescription of each of these layers follows. Desirably, for both non-SISand SIS implementations, the PHY 200 and the communications stack arethe same. It is to be appreciated that such commonality in these layersenables SIS devices to be connected to existing fieldbus Architectureswithout requiring changes to communications protocols currently utilizedby non-SIS devices. As such the physical layer 200 and communicationsstack 205 are described herein with regards to a common or generic(i.e., non-SIS) fieldbus Architecture.

Physical Layer

As shown in FIGS. 1 and 2, the physical layer 200 receives messages fromthe communication stack 205 and converts the messages into physicalsignals on the transmission medium 120/120′ and vice versa. The physicallayer 200 may be defined by approved standards from the InternationalElectrotechnical Commission (IEC) and the International Society ofMeasurement and Control (ISA). For more information about the physicallayer 200, see ISA document S50.02-1992 and IEC document 1158-2, both ofwhich are hereby incorporated by reference in their entirety. It is tobe appreciated, however, that the physical layer may also be defined byother standards commonly known in the art.

In the embodiment shown, the messages are encoded using the well knownManchester Biphase-L technique and the clock signal is embedded in theserial data stream. Again, other encoding schemes may be utilized, asdesired and/or specified by the implementation and networking standardsutilized in any particular embodiment. The hardware required totranslate inbound messages from the bus 120/120′ and outbound messagesfrom a processor within the device is generally called the mediumattachment unit, such as a network adapter. After the physical layer 200translates an inbound message from the bus 120/120′, it forwards it tothe communications stack 205. The communication stack 205 is describedbelow.

Communications Stack

FIG. 2 shows a preferred communications stack 205. In this embodiment,the communication stack 205 includes the data link layer 210, thefieldbus access sublayer 220 and the fieldbus message specification 230.Again, these layers (205, 210, 220 and 230) are desirably common to bothSISCs and non-SISCs. Also, for at least one embodiment, the data linklayer is the same as OSI layer 2, while the fieldbus access sublayer 220and fieldbus message specification 230 are sublayers within the OSIapplication layer, OSI layer 7. The communications stack 205 does notuse layers 3-6. The layers of the communications stack 205 are describedbelow.

Data Link Layer

The data link layer 210 controls transmission of messages onto the bus120/120′ from a link active scheduler 100/100′, link master device105/105′ or basic device 110/110′ based on the instructions receivedfrom a network controller or the link active scheduler 100/100′. In apreferred embodiment, the data link layer 210 is a subset of the IEC andISA data link layer standards.

The link active scheduler 100/100′ controls the data link layer 210according to a network schedule stored in a memory. The network scheduleis a list of transmit times for data buffers within the system. The databuffers store data collected by the field devices. For example, if thefield device is a thermometer, the data buffer stores the temperature,and upon command, publishes the temperature reading onto the bus120/120′. Additionally, the link active scheduler 100/100′ can identifyall the field devices operating on the system because it maintains a“live list.” The link active scheduler 100/100′ maintains the live listby periodically transmitting a pass token message. Any field deviceproperly responding to the pass token is kept on the live list. If afield device fails to respond to the pass token after a predeterminednumber of attempts, the device is removed from the live list. Sincemultiple networks may be connected by bridges and otherwise, in oneembodiment, each link active schedule 100/100′ desirably keeps a “livelist” for those components on each respective network.

New devices can also be added to the live list. The link activescheduler 100/100′ periodically sends probe node messages to networkaddresses not listed in the live list. If a field device is present atthe network address and receives a probe node message, the field deviceimmediately returns a probe response message. If the field deviceanswers with a probe response message, the link active scheduler100/100′ adds the field device to the live list and confirms the fielddevice's addition by sending the field device a node activation message.

Whenever a field device is added or removed from the live list, the linkactive scheduler 100/100′ broadcasts the changes to the live list to allfield devices. This allows each field device to maintain a current copyof the live list.

The link active scheduler 100/100′ also schedules the communicationsfrom other field devices operating in the system. The link activescheduler 100/100′ coordinates the timing of each communication byissuing compel data messages at the scheduled times. Upon receipt of thecompel data message, the requested field device broadcasts or publishesits data to the other field devices operating in the system. To assureproper synchronization, the link active scheduler 100/100′ alsoperiodically broadcasts a time distribution message on the bus 120/120′so that all field devices have exactly the same data link time. The timedistribution message is a message which includes the data link time. Thedata link time is the system time of the link active scheduler 100/100′.When the time distribution message is received by the link masters105/105′ on a given bus, the link masters 105/105′ reset or recalibratetheir individual system times to the data link time.

The remaining operations are performed between scheduled messages ordata exchanges. The link active scheduler 100/100′ grants permission toother field devices to use the bus 120/120′ by issuing a pass tokenmessage to an individual device. When the individual field devicereceives the pass token, the field device is allowed to send messagesuntil the field device is finished sending messages or until the maximumtoken hold time has expired, whichever is shorter. The token hold timeis the amount of time the device can send messages after receiving thepass token. This method of control management is commonly called tokenpassing control. A variety of techniques for implementing token passingcontrol are well-known to those skilled in the art.

To control the data exchanges each device/component preferably includesan input snap 240, processor 250, memory 255, contained parameters 257and output snap 260, and a medium attachment unit 612, as shown in FIGS.3 and 8. The input snap 240 and output snap 260 protect parameter valuesfrom write access or other external interferences during execution of ablock. The processor 250 processes the execution of stored blocks aswell as the algorithms and programs within the blocks. The snappedparameters and contained parameters 257 are stored in the memory 255.The memory is preferably EEPROM or FLASHROM to permit programming of thedevice without the danger of losing data due to power loss. Inalternative embodiments, the memory 255 may be ROM, RAM, or EPROM.

Fieldbus Access Sub-Layer

Referring again to FIG. 2, the next layer in the communications stack205 is the fieldbus access sublayer 220. The fieldbus access sublayer220 uses the scheduled and unscheduled data exchanges of the data linklayer 210 to provide a service for a fieldbus message specification 230.Again, this sublayer 220 is desirably the same in both SIS and non-SIScompatible devices. The service provided by the fieldbus access sublayer220 is the efficient addressing of commonly sent messages. Some examplesof fieldbus access sublayer services are called virtual communicationrelationships (VCRs). FIG. 4 shows three types of VCRs: client/server251, report distribution 252, and publisher/subscriber 254. Other VCRsmay exist, however, in other implementations of the present invention.

The client/server VCRs 251 are used for operator messages, such as thetypes of messages listed in FIG. 4. Specifically, client/server VCRs 251are queued, unscheduled, user-initiated, one-to-one communicationsbetween field devices and/or components within field devices, includingSISCs. Queued means that the messages are sent and received in the orderthe messages were submitted for transmission without overwriting theprevious message. In a preferred embodiment, a field device can send amessage requesting a data exchange when the field device receives a passtoken message from the link active scheduler 100/100′. The requestingdevice is called the client. The device that receives the request iscalled the server.

The server responds when it receives a pass token message from the linkactive scheduler 100/100′. As is discussed in greater detailhereinbelow, when SISCs are involved in client/server data exchanges,additional message and sender verification techniques, such as those setforth in the SISRP, are used to ensure the proper Safety Integrity Level(“SIL”) is achieved.

The report distribution VCRs 252 are used for event notification, suchas alarm notifications to operator consoles and trend reports.Specifically, the report distribution VCRs are queued, unscheduled,user-initiated, one-to-many communications. The report distribution VCRs252 allow a device to send a message to a common address, such as “ALLOPERATOR CONSOLES.” Desirably, report distribution VCRs for SISCs andnon-SISCs are identical. It is to be appreciated that SIL considerationscommonly do not arise with respect to reporting events because of thebuilt-in safeguards present in SIL compatible components, namely, theirpre-programming to accomplish certain “safety” functions or actions whenan erroneous condition is detected.

The publisher/subscriber VCRs 254 are used for publishing data.Specifically, the publisher/subscriber VCRs 254 are buffered,one-to-many communications. Buffered means that only the latest versionof the data is maintained within the network. New data overwritesprevious data. In the preferred embodiment, a field device publishes orbroadcasts messages to other field devices on the bus 120/120′ when thefield device receives a compel data message from the link activescheduler 100/100′. The publisher/subscriber VCR 254 is used by thefield devices for scheduled publishing of user layer function blockinputs and outputs. The publishing of user layer function block inputsand outputs is discussed in more detail later. As is discussed ingreater detail hereinbelow, when SISCs are involved inpublisher/subscriber data exchanges, utilize additional message andpublisher verification techniques, such as those provided in the SISRP,are used to ensure the proper Safety Integrity Level (“SIL”) isachieved.

Fieldbus Message Specification (“FMS”)

Another layer in the communications stack 205 is the fieldbus messagespecification (“FMS”) 230. The FMS 230 allows function blockapplications to send messages to each other using a standard set ofmessage formats. The FMS 230 describes communication services 270,message formats and protocol behavior needed to build a message for theuser layer 240, as illustrated in FIG. 5. In one embodiment of thepresent invention, the formatting of FMSs is defined by a formal syntaxdescription language called Abstract Syntax Notation 1 developed byInternational Telegraph and Telephone Consultive Committee. In otherembodiments, the format of FMSs are otherwise defined using commonlyknown message descriptive languages.

Data that is communicated over the bus 120/120′ is described by anobject description. As illustrated in FIG. 6, object descriptions 280are collected together in a structure called an object dictionary 281.The object descriptions 280 are identified by an index number 285. Anindex number is a cross reference to the location where a particularobject description is stored in memory. Index zero 287, called theobject dictionary header, provides a description of the dictionaryitself and defines the first index for the object descriptions of thefunction block application 440.

In a preferred embodiment, index numbers 1-255 define standard datatypes, such as Boolean, integer, floating point, bit string, and datastructures, that are used to build all other object descriptions 280.The index numbers above index number 255 cross reference user layerobject descriptions 280.

The communication services 270, shown in FIG. 5, provide a standardizedway for user layers 235/235′, both SIS and non-SIS compatible, tocommunicate over the fieldbus. Some examples of communication services270 are context management service, object dictionary service, andvariable access. In one embodiment, the context management services areused to establish and release virtual communication relationships with avirtual field device. The object dictionary service allows the userlayer 235/235′ to access and change the object descriptions in a virtualfield device. The variable access services allow the user layer 235/235′to access and change variables associated with an object description.

In addition, the communication services 270 allow the fieldbus messagespecification 230 to communicate with the virtual field devices 310, 400in the user layer 235/235′. As shown in FIG. 7A, a field device willhave at least two virtual field devices, a network and system managementvirtual field device 310 and a user virtual field device 400.

The network and system management virtual field device 310 typicallystores network management data 320 and system management data 330. Thenetwork management data includes a network management information base(NMIB) object descriptions portion 322 and a NMIB object data portion325. The system management data 330 includes a system managementinformation base (SMIB) object descriptions portion 332, and a SMIBobject data portion 335. The user virtual field device 400 includesblock object data 327 including block object description 326.

The system and network management information base object descriptions322, 335 describe the system and network format for the system andnetwork management information base object data 325, 332.

In one embodiment, a few standard communication profiles are used toallow field devices to communicate and work together on the sametransmission medium 120/120′. The communication profiles preferably usedin function block applications 440 are defined dependent on the fielddevices category or class. Also, to configure and maintain field devicesand their function block application, a common file format isrecommended.

As shown in FIG. 7B, the combination of the bus 120/120′, mediumattachment unit 612 (FIGS. 8A and 8B), physical layer 200, data linklayer 210 and the communications stack 205 are considered to form a“black channel” (as illustrated by the hashed blocks) 207. The blackchannel 207 provides for a standardized communications network andinterconnections between SISCs and non-SISCs without requiringadditions, deletions or modifications to the communications protocolsand configurations currently being utilized to support communicationsbetween non-SISCs in one or more field devices using a fieldbusArchitecture.

User Layer

The user layer 235 processes the information gathered by the fielddevice operating in the system. As shown in FIG. 2, the user layer 235is an additional layer added to the OSI model. As shown in FIG. 7A, theuser layer is generally composed of a network and system managementapplication 430 and at least one function block application 440. Eachwith its own virtual field device described above.

The function block application 440 defines the field device'sfunctionality. A function block application 440 includes one or moreresources 500/500′, as shown in FIG. 8A for a field device having one ormore non-SISCs and as shown in FIG. 8B for a field device having one ormore SISCs. A field device may contain resources that include SISCs andnon-SISCs. A resource 500/500′ is a logical subdivision within thesoftware and/or hardware structure of a device. A resource 500/500′ hasindependent control of its operation, and its definition may be modifiedwithout affecting related resources.

Additionally, in SIS components, an SIS sublayer, which provides theSISRP, 328, as shown in FIG. 7A, is included in the function blockapplication 440. This sublayer/protocol 328 is discussed in greaterdetail hereinbelow.

Introduction

As shown in FIGS. 8A and 8B, both non-SISC related resources 500 andSISC related resources 500′ are built of blocks and objects, such as: aresource block 510 or SIS resource block (“SISRB”) 510′, transducerblock 520 or SIS transducer block (“SISTB”) 520′, function block 530 orSIS function block (“SISFB”) 530′, trend objects 560, view objects 565,link object 570 and/or SIS link object 570′, alert objects 585, systemtime 601, function block schedules 602, and network traffic. Networktraffic includes scheduled and unscheduled traffic. In an SIS device,the resource should contain one or more SISFBs and SISTBs. It is to beappreciated that SISRBs, SISTBs and SISFBs are a few examples of SISCs.Additionally, the SIS resource should be designed to detect faults thatoccur outside of the resource. A brief description of the blocks andobjects used in at least one embodiment of the present invention isprovided below.

A function block 530 represents the basic automation functions performedby a resource, such as an analog input, analog output, orproportional/derivative (PD), or any other function required for processor manufacturing control devices. Function blocks 530 are designed to beas independent as possible of the specifics of input/output devices andthe network.

In SIS devices, the SISFB 530′ is commonly limited to publishing data toanother SISFB as well as non-SIS function blocks designed for use inprocess applications. However, an SISFB desirably can only subscribe todata published by another SISFB in order to ensure compliance with agiven SIL standard. Each SISFB is desirably identified by a uniqueprofile number. In one embodiment of the present invention, such profilenumber is specified by the Fieldbus Foundation. Further, an SISFBdesirable enables the distribution of SIS control into and amongfieldbus components connected to a fieldbus Architecture. In certainpreferred embodiments of the present invention, SISFBs are limited to adefined set. One such set of SISFBs may include analog input, analogoutput, discrete input, discrete output, analog voting, discrete voting,lock change, and logic. Similarly, other embodiments may provide forSISFBs being provided in one or all of three classifications such asinput function blocks, output function blocks and control functionblocks.

Each function block 530/530′ uses input parameters according to aspecific algorithm and internal set of contained parameters. Inputparameters are structured parameters composed of a value field and astatus field. The data type specified for input parameters is dependenton the data type of its value field. The status field is identical forall input parameters. Contained parameters may be used to provide valuesto the block algorithm. The values of the contained parameters may beset by the manufacturer or as part of the configuration. Generally, thecontained parameters may also be set during operation. The inputparameters and contained parameters are processed according to thespecific algorithm to produce output parameters. The output parametersare available for use within the same function block 530/530′ or byother function blocks 530/530′.

Transducer blocks 520/520′ can preprocess and post-process data betweenthe function blocks 530/530′ and field devices, such as sensors,actuators, and switches. Transducer blocks 520/520′ can control accessto the input/output devices through a device independent interface usedby function blocks 530/530′. Transducer blocks 520/520′ can also performfunctions, such as calibration and linearization. SISTBs are desirablydesignated by a unique profile number, such as one assigned by theFieldbus Foundation. Further, transducer blocks 520 may receive inputsfrom non-SISFBs and/or SISFBs. However, SISTBs 520′ desirably may onlyreceive inputs from other SISCs, such as SISFBs, SIS resource blocks,and/or other SIS compatible blocks.

Also, since an SISFB can not assume that an underlying system managementkernel (“SMK”) is fault free, since the SMK is part of the blackchannel, the SISFB may include a parameter which functions as a watchdogtimer. Such watchdog timer suitably aids in the detection of errors inthe scheduling of blocks, such as errors arising from the black channelerroneously scheduling a function block. In one embodiment, a “period ofexecution” parameter may be utilized as a watchdog timer. Such parameterdesirably may be written by SIS compatible configuration devices.Additionally, each output SISFB desirably monitors its execution andresets the watchdog timer (period of execution parameter) each time theblock executes. More particularly, if the watchdog timer expires or isupdated at too fast of a rate, desirably all of the outputs for theaffected SISC(s) will be set to a safe state. It is to be appreciatedthat a “safe state” is commonly component and implementation specific.

As further shown in FIGS. 8A and 8B, a resource 500/500′ also commonlyincludes one or more link objects 570/570′. In a non-SIS device, a linkobject 570 exchanges data between function blocks 530 within a resource500 or between resources. The data exchanged by the link object 570 caninclude process data or events. In addition, the link object 570 canexchange trend report data or alert notification data.

In an SIS device, SIS link objects (“SISLO”) are utilized. In additionto providing the before mentioned functions and capabilities, SISLOs areenhanced link objects that utilize an extended safety-related protocol,such as the SISRP, which include parameters that specify the mappingbetween two SISCs, for example, between an SISFB, an SISRB or an SISTBand a host, regardless of whether the SISFBs are located in a host oranother field device or component. It is to be appreciated that othermapping between SISFBs, SISTBs, SISRBs, hosts, and non-SISCs may beprovided as needed to accomplish particular implementations of thepresent invention. Such link object mapping parameters enable asubscriber to detect errors that may be induced by an underlying blackchannel. Desirably, SISCs communicate with each other using the SISRP.The SISRP is described in greater detail hereinbelow.

A resource block 510 makes the hardware specific characteristics of adevice accessible to the network. The resource blocks 510 insulate thefunction blocks 530 from the resource hardware by including a set ofimplementation independent hardware parameters. However, in componentswhich contain one or more SISCs, the resource block must be an SISresource block (“SISRB”) 510′ because, as mentioned above, SISCspreferably are configured to only subscribe to information provided byother SISCs. SISRBs are desirably designated by a unique profile number,such as one assigned by the Fieldbus Foundation. Also, SISRBs desirablyinclude a parameter, for example “SIL_LEVEL_SUPPORTED,” that specifiesthe maximum SIL level of an application in which the component may beutilized.

View objects 565 and trend objects 560 provide efficient access toparameter data within a function block application 440. View objects 565allow groups of parameters to be accessed by executing a singlecommunication request. Trend objects 560 allow a collection of parametersamples to be reported in a single communications transfer. For at leastone embodiment of the present invention, view and trend objectsassociated with SISCs may be communicated using normal or “SIS”client-server, publisher-subscriber or other communication mechanisms.

Alert objects 585 support the reporting of events to an interface deviceand other field devices. Upon detection of a significant event, afunction block 530/530′ may send an alert message using an alert object585. A significant event is an event that affects system operation.Desirably, the various embodiments of the present invention can reporttheir own errors, alerting operators to problems on a “real-time” basis,as desired. Thus, the various embodiment of the present inventiondescribed herein may improve the productivity of any given operation by,desirably, reducing down time, and increasing operator and plant safety.

System time 601 is provided by system management to function blockapplications (i.e., one or more resources) 440 for use in synchronizingoperations between field devices. Each device 100/100′, 105/105′,110/110′ keeps its own system time 601. Each device 100/100′, 105/105′,110/110′ uses its system time to control the execution of its internalfunction blocks. Time stamping of alarms, events, and trend informationis based on system time 601 maintained by each device.

System management coordinates the execution of the function blocks530/530′ according to a system schedule. The system schedule is a listof execution times for function blocks within a device. Additionally,the execution of a function block 530/530′ may also be invoked by thecompletion of the execution of another function block 530/530′. Systemmanagement is described in more detail later.

Application Framework

Once the components (i.e., the blocks and objects) are implemented, theyare completed or connected by an application framework. The applicationframework coordinates the communication between components internallyand externally. Internal communication means communication betweenfunction blocks 530/530′, regardless of whether they are in the samefield device. External communication means communication between fielddevices with function blocks 530/530′ and field devices without functionblocks. Ideally, the connection of these blocks by the applicationframework results in a modular system allowing the functionality of anapplication to be more extensible and portable. The functionality isextensible in the sense additional functionality can easily be added toan existing function or component. The functionality is portable in thesense that functionality can easily be moved from one location, deviceor component in a system to another or even from one system to another.

FIG. 9 shows some examples of external communications. Specifically,FIG. 9A shows the communication of field devices 620 and a monitordevice 650, a temporary device 660, and an interface device 670. Unlikethe field device 620, the other devices 650, 660, 670 containapplications which are not implemented as function blocks. The monitordevice 650 is connected to the application framework, but does not havea network address. A monitor device monitors communications on thenetwork (e.g., a diagnostic tool may be a monitor device). A temporarydevice 660 supports diagnostics and adjustment of parameter values. Aninterface device 670 provides an operator interface, controlapplications, and/or configuration and diagnostic support.

Similarly, FIG. 9B shows an example of external communications which maybe supported between an SIS control subsystem 910, such as one whichmight exist on bus 120′, and a non-SIS control subsystem 920, such asone which might exist on bus 120. In this illustrative example, SIScontrol subsystem includes two SIS devices, SIS Device A 930 and SISDevice B 940, and non-SIS control subsystem 920 includes two non-SISdevices, Device C 950 and Device D 960. An SIS Application A 970 isimplemented between Devices A and B, 930/940, using SISCs. Additionally,a non-SIS Application B 980 is implemented between Devices C and D950/960, using, among other things, non-SISCs such as standard functionblocks, transducer blocks, resource blocks and link objects.Communications between SIS Devices A and B 930/940 and non-SIS Devices Cand D 950/960 are also supported using common function, transducer andresource blocks, link objects, view objects, alert objects andotherwise. As mentioned previously above, SIS Device A (or B) maypublish information to SIS Device B (or A) and to non-SIS Devices C andD. However, non-SIS Devices may only publish information to non-SISDevices. Desirably, when an implementation such as the one shown in FIG.9B is first implemented, SISCs in the fieldbus devices/components aretested and registered with a suitable testing facility, such as oneprovided by the Fieldbus Foundation, to ensure interoperability betweenSIS and non-SIS fieldbus devices using standard function blocks and/orSISCs.

Further, write access to SISCs (e.g., SISFBs, SISTBs, and SISRBs) may berestricted to a list of interface devices. The list is desirablypre-configured in the device by a configuration system. The SISCs onlygrant write access to this list of devices. The write access for SISCsmay also be “locked’ or similarly configured to prevent the changing ofany safety related parameters while the SIS device or SISC is online orin an otherwise undesirable condition (for example, during certainpotentially human or equipment hazardous maintenance procedures).Desirably, an alert is generated to an operator whenever a write statusis changed. Also, each connection between SISCs is identified by aConnection Key (“CK”). CKs are described in greater detail hereinbelow.Further, the Protocol Data Unit (“PDU”) containing the data written orread to a given SISC is enhanced to include an authenticator, such as aCyclic Redundancy Check (“CRC”). In one embodiment of the presentinvention, a 32 bit CRC is used to authenticate the validity of datacommunicated over a black channel by calculating such CRC using thetransmitted data, a connection key and other information, as isdescribed in greater detail hereinbelow. CRCs and the calculation ofCRCs are well known in the art. Further, it is to be appreciated thatCRCs equal to or greater than 32 bits may be utilized in conjunctionwith the various embodiments of the present invention to authenticatedata transfers at SIL 1, SIL 2, SIL 3 and/or higher levels.

CRC-32 may be used various embodiments of the present invention, asdiscussed in greater detail hereinbelow, to protect against corruptedmessages, addressing failures, such as masquerading, and expansion of amessage. The CRC-32 may also be utilized, in other embodiments of theinvention, to protect other commonly known in the art errors or invalidmessaging conditions.

In addition to external and internal interactions, a variety of otherpossible interactions are well known to one of ordinary skill in theart. For example, there may be interactions with configurationapplications, interactions with a human interface application,interactions with other control applications, interactions for theestablishment of function block links, interactions with otherresources, interactions with system management, and many more.

Function Block Application Structure

As stated above, a function block application 440, for both SIS andnon-SIS devices, defines the functionality of the field device, andincludes one or more resources 500/500′. A resource is a logicalsubdivision within the software and/or hardware structure of the device.Although not shown, function block applications 440 are generallyimplemented using multiple resources. As shown in FIGS. 8A and 8B, theresources 500/500′ which make up a function block application 440 may bemodeled as a set of SISCs (i.e., blocks or objects) coordinated toexecute a related set of operations.

A block is a logical processing unit of software comprising a named copyof the block and parameter data structure specified by function type. Anamed copy of the block is an encapsulated software processing unit,such as an algorithm or computer program. The block is encapsulated tocreate a modular system with the flexibility for upgrades orimprovements. The software processing unit can include a computerprogram and parameters. The software unit is designed to be independentof other blocks and perform a function which can be used in manydifferent function block applications.

A block is identifiable by its class or subclass. The class of a blockindicates its parameters, and how the parameters affect the execution ofthe software processing unit. A block class specifies the commonattributes shared by all instances of the class, including blockelements (e.g., input and output events, contained parameters, andcommon function) and association with resource function (e.g., alarmnotifier and function block services). Each block subclass assumes allthe parameters specified by the class, as well as the additionalparameters attributed to the subclass.

Block classes are classified as elementary or composite. A compositeblock class is one whose algorithm requires the invocation of functionsand/or component blocks of the composite block. An elementary block hasa fixed algorithm and does not require the use of component functions orfunction blocks. Specific examples of elementary and composite blocksare described in detail later.

Function Block Application Hardware

In the preferred embodiment, each device contains at least one functionblock application 440. To execute the function block application 440, adevice usually contains an input snap 240, processor 250, memory 255,output snap 260, and execution control 265, as shown in FIG. 3, as wellas the communications stack 205 and medium attachment unit 612, as shownin FIGS. 8A and 8B.

The medium attachment unit 612, such as a network adapter, receivessignals from other devices over the transmission medium 120/120′ andtranslates the signals into a message for the processor 250. Forexample, the medium attachment unit 612 converts or translates a messagefrom the processor 250 into a signal for transmission over thetransmission medium 120/120′, or a signal from the transmission medium120/120′ into a message for the processor 250.

The input snap 240, processor 250, memory 255, and output snap 260 arefor executing the transducer blocks, function blocks, and resource blockwithin a function block application. Specifically, the input snap 240receives and holds input parameters. These input parameters may beconstant or received from other function blocks. The processor 250executes or processes a software program or algorithm based on theseinput parameters and any contained or stored parameters. Theseparameters are discussed in more detail below. The processor 250 ispreferably a microprocessor or programmable logic array. Any softwareprograms or parameters used by the processor 250 are stored in thememory 255, which is preferably EEPROM or FLASHROM. The functionality ofthe function block application 440 is only limited by the size of thememory 255 and the processing speed of the processor 250. The output ofthe processor 250 is then sent to an output snap 260.

The input snap 240 and output snap 260 are responsible for protectingparameter values from external interferences, such as write access,while the processor 250 is executing. In other words, once the processor250 begins processing the inputs, the input snap 240 and output snap 260hold the inputs and outputs constant until the processing is complete.

Parameters

Parameters define the inputs, outputs, and data used to control blockoperation. The parameters are accessible over the network.

An input parameter obtains its value from a source external to theblock. An input parameter may be linked to an output parameter ofanother block within its resource 500/500′ or within another device. Aninput parameter is an input variable or constant which is processed bythe algorithm or program of a function block 530/530′.

An output parameter is a parameter which may be linked to an inputparameter of one or more blocks. Output parameters contain both valueand status attributes. The output status attribute indicates the qualityof the parameter value generated.

A contained parameter is a parameter whose value is configured,calculated, or set by an operator or higher level device. In thepreferred embodiment, a contained parameter cannot be linked to anotherfunction block input or output, and therefore may not contain statusattribute.

Parameter Identifiers

Each parameter is characterized by its identifiers, storage, usage, andrelationship to other parameters. Each parameter can be characterized bymore than one identifier. For example, a parameter within a block isuniquely identified by its parameter device identification, and aparameter within a system is uniquely identified by its deviceidentification and tag. Tags provide a unique symbolic reference to eachblock within the system.

The data type for a parameter is specified by its data type index. Thedata type index is the object dictionary index of the data type. Thedata type index specifies the machine independent syntax of theparameter. Preferably, the machine independent syntax of the parameteris an abstract syntax. The user layer 235 encodes/decodes the dataaccording to the transfer syntax rules in the fieldbus messagespecification 230. Additionally, a variety of other parameters may alsobe stored in the object dictionary 281 and referenced by its objectdictionary index number.

Parameter Storage

Parameter attributes may be classified as dynamic, static, ornonvolatile. Dynamic parameters are values calculated by the blockalgorithm and, therefore, do not need to be restored after powerfailure.

Static attributes are a specific, configured value that must be restoredafter a power failure. An interface device 670 or temporary device 660may write to static parameter attributes on an infrequent basis. Staticparameter attributes can be tracked by a configuration device.

Non-volatile parameter attributes are written on a frequent basis andthe last saved value must be restored by a device after power failure.Since the values of these parameter attributes are constantly changing,the values can be tracked by a configuration device.

Parameter Relationships

The execution of a block involves input parameters, output parameters,contain parameters, and the algorithm or computer program stored withinthe block. The execution time for a block's algorithm is defined as anattribute of the block. The length of execution time is dependent on thehardware and software implementation.

In simple blocks, input parameters are received before block execution.When the block begins execution, the input values are snapped to preventthem from being updated while they are used by the algorithm.

However, before these input parameters are processed, the inputparameters are used to determine if the algorithm can achieve thedesired mode. In a preferred embodiment, a function block applicationcan achieve a variety of modes, such as out of service (O/S),initialization manual (IMan), local override (LO) manual (Man),automatic (Auto), cascade (Cas), remote-cascade (RCas) and remote output(ROut) mode. The out of service, initialization manual, and localoverride modes are described below. For SISFBs, desirably, inputfunction blocks, such as analog input or discrete input, support modesO/S and Auto. Similarly, for output function blocks, modes O/S, Cas andLO are desirably supported.

When a block is in OS mode, the block is not being evaluated, and theoutput is maintained at the last value.

When a block is in the IMan mode, the block output is being set inresponse to the back calculation input parameter status. When the statusindicates there is no path to the final output element, then the controlblocks initialize to provide for bumpless transfer when the conditionclears. A back-calculation output parameter is supported by all outputand control class function blocks. The set point may be maintained or,optionally, initialized to the process variable parameter value.

The LO mode applies to control and output blocks that support a trackinput parameter. The LO mode may be enabled by a local lock-out switchon the device or a variety of other ways. In the LO mode, the blockoutput is being set to track the value of the track input parameter. Theset point may be maintained or, optionally, be initialized to theprocess variable parameter value.

The determination of whether the block is able to achieve the desiredmode is made by comparing the actual mode attribute and the target modeattribute. The actual mode attribute reflects the mode of operationwhich the block is able to achieve. The target mode attribute indicateswhat mode of operation is desired for the block. The target mode isusually set by a control application or by an operator through a humaninterface application.

Once the actual mode is determined, the block execution progresses andthe outputs are generated. If alert conditions are detected, alarm andevent output parameters are updated for reporting by an alert object.When the execution is complete, the outputs are snapped making themavailable for external access. Prior to being snapped, only the previousvalues are available for external access.

Resource Components

As stated above, a function block application 440 contains one or moreresources, and a resource 500/500′ includes one or more blocks. A blockis identifiable by its class or subclass. The class of a block indicatesits parameters, and how these parameters affect the execution of itsalgorithm or program. The Resource Components Section provides theformal models for the preferred classes. Preferred classes include aresource class, directory object class, block object class, parameterobject class, link object class, alert object class, trend object class,view object class, domain object class, program invocation object class,and an action object class. In alternative embodiments, someone skilledin the art could define a system with more, less, or different classes.Again, domain object, program-invocation objects and action objects arenot supported in SISC.

Resource Class

The resource class defined in a preferred embodiment specifies thedescriptive attributes of the resource. The object dictionary of eachresource contains a description of the components contained within theresource. The resource class includes the following attributes: resourcename, vendor name, model name, revision, logical status, physicalstatus, object dictionary and, in SIS devices, the SIL level supportedby the device.

The vendor name identifies the vendor of the software and/or hardwareassociated with the resource. The model name specifies the model of thesoftware and/or hardware associated with the resource. The revisionattribute is the revision level of the software and/or hardwareassociated with the resource. The logical status attribute containsinformation about the communication functionality associated with theresource. The physical status attribute gives a coarse summary of thehardware component associated with the resource. The object dictionarycontains the attributes of an object dictionary directory object,resource block, and other objects specific to the function blockapplication 440 process. Each of these attributes are accessible throughthe fieldbus message specification 230.

Someone skilled in the art will recognize these attributes and theattributes defined for any class or subclass are only illustrative ofthe attributes that could be used. In alternative embodiments, theresource class or any other class or subclass could include more, less,or different attributes. This concept applies to all of the classes andsubclasses described in this specification.

Directory Object

Another preferred class is the directory object class. A directoryobject acts as a guide to other blocks and objects within a resource orfunction block application 440. The directory object contains a list ofreferences to the other blocks and objects making up a resource orfunction block application 440. This information may be read by aninterface device or temporary device desiring to access objects in theobject dictionary. The directory object class is defined as includingthe following attributes: member identification; starting index of thestatic object dictionary; data type; sub-index entries; data length;usage; storage; list of valid values; initial value; and itemidentification.

The member identification attribute is the unique number whichidentifies the function of the directory. The index is the index of thedirectory object in the object dictionary. The various data typesinclude meta type or type name. Meta type indicates the object type.Type name specifies the name of the data type of the object. The subindex entries allow the attributes of a directory object to be accessedindividually through the read and write service. The data lengthattribute specifies the number of bytes reserved to represent the subindex values in the directory. The usage attribute indicates that thisis a contained object and may not be referenced by link objects forconnection to function block parameters. The storage attribute indicateswhether the parameter is stored in static memory. The list of validvalues specifies the values permitted for the sub index attributes ofthe directory object. The initial value specifies the initial valueassigned to the sub index attributes of the object directory, and theitem identification identifies the description of the object.

Block Object

The block object preferred class specifies the characteristics common tothe function blocks, transducer blocks, and resource blocks. In theobject dictionary, parameters follow continuously after the blockobject, each having an index. The block object class is defined by thefollowing attributes: member identification; block index; data type; subindex; data length; usage; storage; list of parameters; list of validvalues; and item identification. The member identification identifiesthe function of the block. The block index is the index of the blockobject in the object dictionary. The data type includes the meta typeand type name. The meta type indicates the object type. The type namespecifies the name of the data structure of the block. The sub indexincludes attributes, such as block tag, member identification, itemidentification, revision, profile, profile revision, execution time,period of execution, number of parameters, next block to execute,starting views, number of view 3 objects, and number of view 4 objects.The data length attribute equals 62. The list of parameters includesstatic revision, tag description, strategy, alert key, mode, and blockerror. The remaining attributes were described above.

The three sub-classes of the block object class used in a preferredembodiment are resource block objects, transducer block objects, andfunction block objects.

Resource Block Object

The resource block object defines hardware specific characteristics ofits associated resource. Because the resource block object is asub-class of the block object model, the resource block object assumesthe list of parameters attributed to the block object, as well as itsown additional attributes. The additional attributes in the resourceblock subclass are: resource state, test, resource, additional containedparameters; execution time=0, period of execution=0, and the next blockto execute=0.

A resource block insulates the function blocks from the physicalhardware by containing a set of implementation independent hardwareparameters. The resource block is manufacturer specific; and all itsparameters are defined as contained.

Transducer Block Objects

Another subclass of the block object class is a transducer block object.Transducer blocks are defined to decouple function blocks from the localI/O functions required to read sensor hardware and command hardware.This permits the transducer block to execute as frequently as necessaryto obtain data from sensors without burdening the function blocks thatuse the data. It also insulates the function block from the manufacturerspecific characteristics of an I/O device.

The transducer block object is a subclass of the block object, and thus,it assumes all the attributes of the block class. The additionalattributes of the transducer block subclass are: additional containedparameters; execution time=0; period of execution=0; and next block toexecute=0.

Function Blocks Objects

Function blocks represent the basic automation functions performed by aresource, such as an analog input or discrete output. Function blocksare the primary means of defining monitoring and control in a functionblock application. They are designed to be as independent as possible ofthe specifics of I/O devices and the network. They work by processinginput parameters and inputs from transducer blocks (or other functionblocks) according to a specified algorithm and an internal set ofcontained parameters. They also produce output parameters and output totransducer blocks or the input of other function blocks.

Based on the processing algorithm, a desired monitoring, calculation orcontrol function may be provided. The results from function blockexecution may be reflected in the output to a transducer block or to oneor more output parameters that may be linked to other function blocks ordirectly to the device hardware.

Function blocks are a subclass of the object class. The additionalattributes defined in the function block subclass are the sub-index ofexecution time, period execution, number of parameters, next block toexecute, and additional parameters.

The sub-index attribute defines the attributes of an object which may beindividually accessed through read and write services by using thesub-index number with the object index number. Sub-index numbers aredefined based on Meta type.

The execution time parameter of the function block object denotes thetime required for a function block to execute. The execution time may bedivided into three components: pre-processing (i.e., snap of parametervalues); execution; and post-processing (i.e., block output values,alarm, and associated trend parameters are updated).

To provide consistent behavior, the block algorithm executed during theexecution component is broken down into the following steps. First, thealgorithm determines the actual mode attribute of the mode parameter.This calculation will be based on the target mode and the status ofattributes of the inputs as described above. Second, the algorithmcalculates the set point, if the set point is defined for the functionblock. The calculation of the set point will be based on the actualmode, set point input parameters, such as cascade and remote-cascade,and any backward path input status. Also, the value of the controlledparameter, process variable, may be used for set point tracking. Theresulting set point is shown in a set point parameter. An example of aset point is the temperature setting of a thermostat (e.g., 72°). Inother examples, the set point will change frequently.

Third, the algorithm executes control or calculation of the algorithm todetermine the value and status of the output parameters. The conditionswhich determine the status attribute of output parameters. The valueattributes of the block's input parameters and contained parameters, theactual mode, and the working set point are used in this algorithm.Generally, the calculation of actual mode and the use of actual mode inthe algorithm account for the status of critical inputs.

Fourth, the execution phase calculates the output parameters. This stepapplies only to output blocks, control blocks, and calculation blocksdesigned to be used in the cascade path.

The period of execution of a function block is typically scheduled on aperiodic basis. The period of execution is user specified based oncontrol or monitoring requirements specific to an application. Thesystem management services coordinate the function block execution. Themanagement information base, which includes the system schedule, isstored in its own resource in the device. The function block period ofexecution is specified for a block in data link layer time. Through thescheduling capability provided by system management, it is possible tophase or stagger the execution of blocks in a device where their periodsof execution time are the same or are integer multiples of each other.System management is discussed in more detail below.

The “number of parameters” attribute within the function block object isthe total number of parameter objects associated with the functionblock, including the block object.

The “next block to execute” attribute of the function block objectspecifies the next function block within a device to execute to achieveminimum delay in execution within a device. If there is no next functionblock, then the next block to execute is zero. Thus, where multiplefunction blocks need to execute in series within a device, a user canspecify the first function block to execute in the chain. Through thenext block to execute attribute, the order of execution can bepredetermined.

The “list of parameters” attribute of the function block object liststhe input, output and contained parameters within a function block.

Based on the common parameters and the behavior, a preferred embodimentalso defines the following subclasses of the function block subclass,including: input function block; output function block; control functionblock; and calculation function block.

The input function block subclass receives physical measurements orvalues from transducer block. The input function block subclass includesa simulation parameter by which the transducer value and status may beover-ridden. The input function block's other parameters preferablyinclude: process variable; primary output; channel number; andadditional parameters.

The output function block subclass acts upon input from other functionblocks and forwards its results to an output transducer block. Theoutput function block subclass supports the back-calculation outputparameter and simulate parameter. The additional output function blockattributes are: set point, simulate parameter, cascade input;back-calculation output; remote cascade in; remote cascade out; andchannel number.

The control function block subclass acts upon inputs from other functionblocks to produce values that are sent to other control or outputfunction blocks. The additional attributes for the control functionblock are: primary output; back-calculation; process variable; setpoint; primary input; cascade input; remote-cascade in; remote-outputin; back-calculation output; remote-cascade out; remote-output out; andadditional parameters. The additional calculation function blockparameters are: back calculation input; back calculation output; andadditional parameters.

Parameter Objects

Returning to the class level, parameter objects are defined to allow thefunction block, transducer block and resource block attributes to beaccessed over the bus. The attributes defined in the basic parameterobject model are: member identification; parameter index; relativeindex; data type; sub index; data length; units; usage; storage; list ofvalid values; initial value; and item identification. Not all theparameters listed are required in a particular block. Additionally, apreferred embodiment also defines several subclasses from the parameterobject class, including output parameter objects, input parameterobjects, and contained parameter objects.

Link Objects

Link objects 570/570′ provide mapping between resources and theinformation exchanged via a communication network as illustrated inFIGS. 8A and 8B. Process data and events to be exchanged betweenfunction blocks within a resource or between resources may be definedthrough link objects. In addition, the communication exchange forsupport of trends and alerts may be defined using link objects.

Link objects 570/570′ are defined in field devices associated with thefunction block applications process. Link objects 570/570′, byreferencing the appropriate VCR, may be used to access, distribute orexchange individual objects. In addition, the link objects define theassociation between input and output parameters, and trend reports,which interface devices must receive.

In SIS implementations, an extended safety/SISRP is utilized. The SISRPprovides for authentication of communications between SISCs such thatSIL-3 and SIL-2 certifications may be attained. In particular, the SISRPprotects against errors that may arise during use of the black channel.Such errors may include: transmission bit failure, such as when a singleor multiple bit(s) in a message changes state on the black channel;retransmission, where the black channel inadvertently retransmits amessage; omission, where the black channel loses a message(s);insertion/expansion, where a message is erroneously generated and/orinserted or expanded on the black channel; wrong order, where the blackchannel delivers messages in the wrong order; delay, where the blackchannel delay transmission or reception of a message for a period oftime; masquerading, where the black channel delivers messages to thewrong endpoint or multiple devices have the same network address;queuing fault, where the black channel delays a message by more than thetransmission rate but less than the time delay needed to cause atimeout; communication and function block scheduling errors; system andconfiguration management errors; and others.

One mechanism by which the SISRP protects against the before mentionederrors is by utilizing a sequence number. Desirably, a sixteen (16) bitnumber is utilized for each VCR connection to identify a sequence ofmessages sent between a sending SISC and a receiving SISC. The receivingSISC maintains a corresponding index number. When operating properly,the index number updates at both the sender and receiver with eachmessage sent. When the maximum number of messages is received, thenumbers wrap and begin counting up from zero (0) again. Assuming amessage transmission rate of a message every ten milliseconds, which isachievable using a High Speed Ethernet connection, the sequence numbersshould wrap every 655 seconds. At lower message transmission rates, thesequence numbers will wrap less often.

If the sent sequence number and the expected sequence number (i.e., thesequence number expected at the receiving component) do not match, thenthe data is considered “stale” or unusable. If such a stale datacondition repeats itself a given, configurable, number of times, then alink between the components may be set as being bad. Such sequencenumbers and the link, generally, will then need to be reset beforecommunications between the effected components are resumed. Further, ina publisher-subscriber relationship, the sequence number desirably isreset on both the sender and the receiver whenever two correctconsecutive messages have been received. For a client-serverrelationship, if the sequence numbers are out of synch, then theconnection is aborted and the sequence numbers are reset upon theconnection being reestablished. However, in other embodiments, sequencenumbers may be reset using other processes and techniques.

Further, by utilizing a sequence number in the SISRP, protection isprovided for retransmission, wrong order and insertion/expansion errors.Additionally, sequence keys are also used in conjunction with CKs in theSISRP to protect against masquerading errors.

As mentioned above for SIS implementations, connection keys (“CKs”) aredesirably utilized. Such CKs are a part of the SISRP and are commonlyprovided as a parameter in SISLOs. The CK is a unique key that isassigned by a configuration system for connection between an interfacedevice and SISCs (i.e., SISFBs, SISTBs and SISRBs) for client-serverconnection. Also, a unique CK is assigned for each publisher-subscriberconnection, wherein all subscribers to a given publisher are desirablyconfigured to use the publisher's key. The utilization of CKs andsequence numbers in client-server and publisher-subscriber connectionsis further described in greater detail hereinbelow.

Also, for SIS implementations the SISLOs preferably include an SISAccess parameter. This parameter, when set, specifies that read andwrite requests are processed using the extended SISRP.

Alert Objects

Alert objects are used to communicate notification messages when alarmsor events are detected. An event is an instantaneous occurrence that issignificant to scheduling block execution and to the operational view ofa function block application 440. An alarm is the detection of a blockleaving a particular state. The alert object class allows alarms andevents to be reported to a device responsible for alarm management.

Based on the type of alarm and event information which may be reportedby blocks, the preferred embodiment designates three subclasses of alarmobjects. They are analog alerts, discrete alerts, and update alerts.Analog alerts are used to report alarms or events whose values areassociated with a floating point. Discrete alerts are used to reportalarms or events whose associated value is discrete. Update alerts areused to report a change in the static data of a block.

Trend Objects

Trend objects support management and control of function blocks byproviding visibility into history information for reviewing theirbehavior. Based on the type of information collected, a preferredembodiment defines three subclasses of trend objects. These subclassesare the trend float subclass, the trend discrete subclass, and the trendbit string subclass. The trend float class collects the values andstatus of floating point input and output parameters. The trend discretesubclass collects the values and status of discrete input and outputparameters. The trend bit string subclass collects the values and statusof bit string input and output parameters.

View Objects

View objects support management and control of function blocks byproviding “visibility” into their configuration and operation. In otherwords, view objects allow the user to monitor or “view” data associatedwith operation, diagnostic, and configuration of the system, functionsblock application 440 or resource 500. In one embodiment of the presentinvention, there are four sub-classes of the view object class. Thesesubclasses are view 1, view 2, view 3, and view 4. View 1 allows accessto dynamic operation parameter values. View 2 allows access to staticoperation parameter values. View 3 allows access to all dynamicparameter values. View 4 allows access to other static parameter values.

Domain Objects

For a non-SIS device, a domain object 580 supports download servicesthat may be used to load data from a client into the server's domain.Data from the server's domain may be transmitted to a client throughdomain upload services. The domain objects are part of memory. They maycontain programs or data. Domains with code and data are combined intoan executable program using a program invocation object.

Other Objects

For a non-SIS device, a program invocation object 590 provides servicesto link domains to a program, to start this program, to stop, and todelete it. Action objects may optionally be supported by a resource in anon-SIS device. Through an action object, an individual block or objectwithin a resource may be deleted in the non-SIS device. Preferably, forSIS devices, action objects are not supported because it is commonlyundesirable to delete safety critical or important blocks or objects.

Function Block—Mapping

For implementation of a function block application 440, the functionblock application 440 is mapped into the virtual field device of thefieldbus message specification 230, as shown in FIG. 7A. The virtualfield objects which are the preferred tools in describing a functionblock application 440 are: variable objects; event management objects;domain objects (in non-SIS devices only); and program invocation objects(in non-SIS devices only).

Variable objects are a type of block parameter. Other types of blockparameters are simple, array, or record. Record objects support trend,action, and link objects. Grouping of information for access may be doneusing variable list objects.

Event notification objects are used for alarm and event notification.Domain objects, which preferably are not available in SIS devices, are acomputer program that may be loaded into memory using the domaindownload services. Program invocation services, which preferably are notavailable in SIS devices, may control function block applicationinitialization. Such services include: to start, to stop, and to reset.

The table below is used to show how the function block application modelmay be mapped directly into the objects defined in the objectdictionary.

Function Block Model Mapping to FMS Resource VFD Directory DirectoryObject Array Block Record Parameters Simple Variables, Array &RecordsViews Variable Lists Link Object Record Alert Object Event Trend ObjectRecord Program Program Invocation Invocation Domain Domain Action RecordIn a preferred embodiment, to coordinate the mapping of the functionblock models into the object dictionary, the device description language(described in more detail later) is used to describe the function blockand support block parameters used by the configuration tool. Such adescription is known as a “device description.” In many cases, the“device description” is used in the configuration and interfacestations. However, in some cases, all or part of the device descriptionmay be stored in the field device. When the device description is storedin the field device, it may reside in its own object dictionary in aresource separate from that used for the function block application. Toaccess the device description information, each block maintains anassociated device description reference number.

The virtual field device collects the blocks and objects discussed aboveinto an object dictionary. Within the object dictionary, each block orobject is addressed by an index number and identified by an objectdescription. The object descriptions generally contain an index, objectcode, further object attributes, and system-specific references to thereal object.

Index Numbers

In a preferred embodiment, the index numbers are grouped according totheir data type or structure, or whether the object is static ordynamic. In the preferred embodiment, object indices 1-255 are reservedfor commonly used data types and data structures. As shown in the tablebelow, indices 1-14 and 21 are defined data types in the fieldbusmessage specification 230, and indices 64-86 are commonly used datastructures, which are referenced in the definition of record objects.These indices are the same as the index numbers 285 shown in FIG. 6.FIG. 10 illustrates how these index numbers can also be grouped bywhether the object is static or dynamic.

Index Type Nam 1 Data Boolean 2 Data Integer 8 3 Data Integer 16 4 DataInteger 32 5 Data Unsigned 8 6 Data Unsigned 16 7 Data Unsigned 32 8Data Floating Point 9 Data Visible String 10 Data Octet String 11 DataDate 12 Data Time of Day 13 Data Time Difference 14 Data Bit String 21Data Time Value 64 Structure Block 65 Structure Value &Status - Float 66Structure Value &Status - Discrete 67 Structure Value &Status -BitString 68 Structure Scaling 69 Structure Mode 70 Structure AccessPermissions 71 Structure Alarm-Float 72 Structure Alarm-Discrete 73Structure Event-Update 74 Structure Alarm-Summary 75 StructureAlert-Analog 76 Structure Alert-Discrete 77 Structure Alert-Update 78Structure Trend-Float 79 Structure Trend-Discrete 80 StructureTrend-BitString 81 Structure FB Link 82 Structure Simulate-Float 83Structure Simulate-Discrete 84 Structure Simulate-BitString 85 StructureTest 86 Structure Action-Instantiate/Delete

All the object descriptions in the object dictionary other than the datatype and data structure descriptions may support extensions. Forexample, the index number of an object description other than a datatype or structure may be changed without affecting the other objects. Inaddition, the object description may also be improved or upgradedwithout affecting the other objects.

Object Dictionary

The object dictionary is defined to act as a guide to the informationwithin a function block application 440. The object dictionary 281 is alist of references to the objects making up that function blockapplication. This information may be read by an interface devicedesiring to access objects in the object dictionary.

The object dictionary directory object 282 will be defined as the firstindex in the static object dictionary (S-OD) 700, shown in FIG. 10. Thestarting point of the static object dictionary is defined by the objectdictionary object description, which resides in Index Zero. In addition,the object dictionary description identifies the start index, the lengthof the dynamic list of variable list (DV-OD) 710 and the dynamic list ofprogram invocation (DP-OD) 720 associated with view objects and programinvocation objects.

In a preferred embodiment, the directory is logically constructed byconcatenating the directory objects, and consists of a header followedby the directory entries. An array offset is specified from the start ofthe logical directory. The logical directory can be thought of as asingle array composed of all the directory object instances. The headeris only present in the first directory object.

The blocks which reside in a resource are identified in the objectdictionary by the directory object. Each instance of a resource block510, function block 530, or transducer block 520 consists of a blockobject and associated parameters. The block object references itsassociated view object 565.

The block object is the primary key used in referencing an instance of ablock. It identifies the block tag, execution time, profile, and numberof block parameters. Also, it identifies the starting location andnumber of view objects for this block. The parameters of a block arelocated continuously in the object dictionary following the blockobject. The block parameter values may be accessed through theseparameter objects. In a preferred embodiment, the block parameterobjects are generally restricted to simple variable parameters, arrayparameters and record parameters.

In a preferred embodiment, several data structures have beenstandardized for the function block application process.

Common Sub-Functions

This section contains descriptions of sub-functions common to manyblocks. A process control function has the following elements: (1) oneor more inputs; (2) one or more outputs; (3) scaling information; (4) amode selector; (5) a selected algorithm; (6) a set of visible dataparameters; and (7) a set of internal data. Each of these elementsrepresents either static data or dynamic data. Static data is data whichis seldom changed, while dynamic data may change with each blockevaluation.

Each instance of a block is processed according to the algorithmselection at a time determined by a combined block execution andcommunication scheduler. The only scheduling information contained inthe parameters of a block is the period of execution and the maximumexecution time.

Connections

A block input contains the data read from outputs of other blocks. If ablock does not receive an input from another block, a constant input canbe entered. The permanence of the value depends on the kind of memory tostore it. The type of memory used depends on the parameters. Forexample, volatile memory is sufficient for a frequently changingparameter. Nonvolatile memory is preferred for set points. Block outputscontain the result of block evaluation, or an operator entry if the modeis manual.

Both inputs and outputs comprise a value field and a status field. Thestatus field contains quality, substatus, and limit attributes. It isthe same for all inputs and outputs.

The input and output function block classes must exchange data with thedevice hardware and this is completely under the control of themanufacturer who writes the device code, as this data never goes throughthe communication system. In the alternative embodiments, many blocksprovide parameters which may be written and read by remote devicesoperating a proprietary control application. To conduct such anexchange, the remote device must execute a handshaking utilizationalgorithm before writing or the block may ignore the input.

Simulation

In a preferred embodiment, all input and output class function blockshave a simulation parameter, which has a pair of status values, and anenable switch. This parameter acts as a switch at the interface betweena function block and the associated transducer block or hardwarechannel. For inputs, the transducer value and status are received fromthe transducer block or hardware channel if the switch is disabled. Whenthe enable switch is on, the simulation parameter and status values arereceived from the function block, and the transducer block or inputchannel is ignored.

For outputs, the simulate value and the status value become the readbackvalue and status when the enable switch is on, and the transducer switchis ignored.

Scaling information is used for two purposes. Display devices use therange for bar graphs and trending. Control blocks use the range aspercent of span, so that the tuning constant remains dimensionless.

Further in SISCs, when the write lock in a resource is activated,simulation capabilities are desirably disabled.

Modes

In a preferred embodiment, all blocks have a mode parameter whichdetermines the resource of the data to be used for the block's input andoutput. All blocks must permit the out-of-service (O/S) mode. To beuseful, a block must support at least one other mode.

The permitted modes apply to the target mode. A write request to thetarget mode is rejected if it does not match the permitted list. Aconfiguration device must not allow a mode to be permitted that is notsupported. The actual mode is not constrained by the permitted mode,because some modes are acquired for initialization.

Parameter Access Table

In a preferred embodiment, there is an access table for each block. Thepurpose of that table is to define the relative position of theparameters within each block, and to define the contents of the standardviews of the parameters.

The block parameters which need to be communicated over the bus varywithin the application. To allow communications among the variousfunction blocks, predefined sets of variables are selected for eachfunction block. The parameters included in these predefined sets offunction blocks are specified in the views in the parameter accesstable. If parameters are added to a block, these parameters are addedafter all the standard parameters.

The parameter access table provides the following: (1) the order inwhich the parameters appear sequentially in the object dictionaryrelative to the location of the associated block object; (2) a list ofparameters associated with the function block address in the table; and(3) predefined parameter sets. The predefined parameter sets includeview 1 through view 4.

View 1 is the operation dynamic parameter set. The operation dynamicparameter set includes information required by a plant operator to viewprocess control, see alarm conditions, and adjust operating targets.

View 2 is the operation static parameter set. The operation staticparameter set includes information which may be required for display toan operator with dynamic information. This information is read once whenthe associated display is first caught up, and refreshed if the staticupdate code changes.

View 3 is the all dynamic parameter set. The all dynamic parameter setincludes information which is changing in value and may need to bereferenced in a detailed display.

View 4 is the static parameter set. The static parameter set includesinformation which is normally referenced during the configuration ormaintenance and has a specific value unless changed by an operator orinstrument technician.

The parameters associated with each block are listed in separate accesstables. The first six indices are identical, which forms a standardheader for all standard and extended function blocks. The remainingindices are for the core parameters of the function and the lesser usedparameters. Finally, there are the parameters required for alarmprocessing, followed by the alarm records.

Other Common Sub-functions

In addition to the common functions discussed above, there are manyothers. In a preferred embodiment, these other subfunctions include:status; back calculation (BKCAL); cascade (CAS); output tracking (TRK);balancing bias or ratio (BIAS or SP); fail safe handling (FSAFE); badcascade status handling; invalid values; parameters; alarms; andinitialization and restart.

Preferred Resource Components

As discussed above, a device includes one or more function blockapplications 440. A function block application 440 includes one or moreresources 500/500′, and a resource 500/500′ includes one or moreblocks/objects. Each resource has a resource block.

In a preferred embodiment, each resource block contains data that isspecific to the hardware that is associated with the resource. The datain the resource block is modeled as contained parameters, so there areno links to this block.

Each function block application also contains at least one functionblock. In a preferred embodiment, there are ten function blocks which,when combined, can provide the vast majority of functions formanufacturing equipment on a process control system. These blocks are:analog input; analog output; bias; control selector; discrete input;discrete output; manual loader; proportional/derivative;proportional/integral/derivative; and ratio. In SIS devices, some butgenerally not all of these types of function blocks may or may not besupported. In one particular embodiment of the present invention,available SISFBs are limited to analog input, analog output, discreteinput, and discrete output. In other embodiments, analog voting, digitalvoting and other function blocks may be supported. Thus, it is to beappreciated that the various implementations of the various embodimentsof the present invention may include some, all, none or others of theabove identified function blocks, some of such function blocks may beSISFBs or non-SISFBs.

In addition, in one embodiment, there are nineteen standardized functionblocks to perform more complex functions, including advanced controlblocks, calculation blocks, and auxiliary blocks. These nineteenfunction blocks are: pulse input; complex analog output; complexdiscrete output; step output proportional/integral/derivative; devicecontrol; set point ramp generator; splitter; input selector; signalcharacterizer; lead lag; dead time; arithmetic; calculate; integrator;timer; analog alarm; discrete alarm; analog human interface; anddiscrete human interface. These blocks address additional requirementsfor both a low and high speed fieldbus.

In a preferred embodiment, there are also standard transducer blocks.

Examples of two target applications, a manual control 760 and asafety-related function 770, using the function blocks are shown in FIG.11. The manual control 760 consist of an analog input function block762, a manual loader 764, and an analog output function block 768. Thesafety-related function 770 consists of a plurality of SIS analog inputs(“SISAI”) 772, an SIS analog voter (“SISAVTR”) 774, and an SIS digitaloutput (“SISDO”) 778.

Device Descriptions (DD)

As shown in FIG. 12, the function block application processes may alsostore device descriptions (DD) 860. To extend the network'sinteroperability, the device descriptions 860 are used in addition tothe standard function block parameters. The device descriptions 860extend the descriptions of each object in the virtual field device.

The device descriptions 860 provide information needed for a controlsystem to interpret the meaning of the data in the virtual field device,including the human interface functions, such as calibration anddiagnostics.

The device description can be written in any standardized programminglanguage, such as C, C++, or SmallTalk.

System Management

In operation, function blocks execute in precisely defined intervals andin proper sequence for correct control system operation. Systemmanagement synchronizes execution of the function blocks and acommunication of function block parameters on the bus. System managementalso handles other important features such as publication of the time ofday to all devices, automatic assignment of device addresses, andsearching for parameter names or tags on the fieldbus.

The configuration information needed by the system management, such asthe system schedule, is described by object descriptions. Theconfiguration information is stored in the network and system managementvirtual field device 310, as shown in FIG. 7A. The network and systemmanagement virtual field device 310 provides access to the systemmanagement information base (SMIB) 330, and also to the networkmanagement information base (NMIB) 320. The system schedules can beinputted manually or built using a schedule building tool. A schedulebuilding tool is used to generate a function block and link activescheduler schedules are used to generate system and network schedules.

Based on the system schedule, system management controls when thefunction blocks execute. This insures that each function block executesat the appropriate time in relationship to other function blocks in thesystem. For a true distributed control system, the activities of thedevices and their function blocks also have to be synchronized withthose of other devices on the network. The coordination of the executionof blocks in different devices is controlled by a network manager usinga network schedule. Network Management is described in detail later.

The system and network schedules contain the start time off-set from thebeginning of the absolute link schedule start time. The absolute linkschedule start time is known by all devices on the fieldbus.

The system management also has a time publisher which, in a link activescheduler 100, periodically sends application clock synchronization toall field devices. The data link scheduling time is sampled and sentwith the application clock message so that the receiving devices canadjust their local application time. Between synchronization messages,the application or system clock time is independently maintained in eachfield device based on its own system clock. The system clock in eachfield device initiates the execution of the system schedule for thatdevice, not the data link clock, unless the field device is the linkactive scheduler 100. System clock synchronization allows the fielddevices to stamp data throughout a network. If there are backup systemclock publishers on the bus, a backup publisher will become the datalink clock if the currently active time publisher should fail.

System management also automatically assigns unique network addresses toeach field device. Every field device, except a temporary device, shouldhave a unique network address and physical tag. Temporary devices arenot assigned tags or permanent addresses. Temporary devices simply jointhe network at one of four data link visitor addresses reserved for themin the data link layer protocol specification.

The system management function responsible for tag and data link addressassignment is referred to as the configuration master. It is normallyco-located with the link active scheduler 100, although it is notrequired to be, so it can monitor the live list for the addition of newdevices. When a device is added at a default network address,configuration master verifies that a system management kernel for thefield device does not have a physical tag and assigns it one usingsystem management kernel protocol 810. Once assigned, the systemmanagement kernel moves to the initialized state. In this state, it isready to be assigned a network address on the operational network. Asystem management kernel is described in detail later.

The sequence for assigning a network address to a new field device is asfollows: (1) a physical tag is assigned to a new device viaconfiguration device; (2) system management asks the field device forits physical device tag default network address; (3) system managementuses the physical device tag to look up the new network address in theconfiguration table; and (4) system management sends a specialset-address message to the device which forces the device to assume thenetwork address. The sequence of these steps is repeated for all devicesthat enter the network at a default address.

FIG. 12 shows the relationship between system management and the othercommunication and application components for one embodiment of thepresent invention. For example, FIG. 12 shows the relationships betweenthe system management and function block application 440, function blockobjects 850, device descriptions (DD) 860, and object descriptions (OD)280. System management also uses the fieldbus message specification 230to remotely access management information within a field device. Systemmanagement also accesses the communications stack 205 to perform itsother functions.

A single system management entity exists in each link master 105/105′ orlink active scheduler 100. This entity comprises a system managementinformation base 830 (SMIB), an object dictionary 280, and a systemmanagement kernel 800.

The system management kernel 800 provides a network coordinated andsynchronized set of functions. To enforce the coordination andsynchronization of these functions across the network, a manager/agentmodel is used. In a preferred embodiment, the system management kernel800 assumes the role of an agent and responds to the instructionsreceived from the system management. A system management protocol isused to define communications between managers and agents.

Information which is used to control system management operation isorganized as objects stored in the SMIB 830. The SMIB 830 is accessed bythe network through the system and network management virtual fielddevice 310. The SMIB 830 contains configuration and operationalparameters for a device. Examples of the objects included in the SMIB830 are: device identification, physical device tag, list of virtualfield devices, time object, schedule object, and configuration status.

The system management allows SMIB objects to be accessed using thefieldbus message specification application services, such as read,write, etc. Access to the SMIB allows remote applications to obtainmanagement information from the device, either before or during networkoperation. The management virtual field device is shared with thenetwork management agent 880 of the device and thereby also providesaccess to network management agent objects.

Network Management

FIG. 12 also shows the architectural relationship between networkmanagement and the other communication and application components in adevice. Each device contains a single network management agent 880 andlayer management entities (LME) 875 for its protocols (one for eachlayer). Each network has at least one network manager which coordinatesthe network management of the whole system. Network management providesthe capabilities of: loading a virtual communication relationship list;configuring the communication stack 205; loading the network schedule;performance monitoring; and fault detection monitoring.

The network manager is responsible for maintaining the operation of thenetwork according to the policies defined for it by the system manager.The network manager enforces the system management policies bymonitoring the status of the communication stack 205 in each device, andtaking action when necessary. The network manager performs these tasksby processing information and reports produced by network managementagents 880, and recommending agents to perform services requested viathe fieldbus message specification 230.

The network management agent 880 is responsible for providing thenetwork manager with a fieldbus message specification 230 interface tomanage objects of the communication stack 205. Internal to the device,the network management agent 880 maps fieldbus message specificationservice requests to objects that it maintains for the communicationstack 205 as a whole, an objects maintained by the LMEs.

The LMEs 875 provide management capability of a layer protocol, such asthe physical layer (PHY) 200, the data link layer (DLL) 210, fieldbusaccess sublayer (FAS) 220 or fieldbus message specification (FMS) 230(as shown in FIG. 2). The LMEs 875 provide the network management agent880 with a local interface to the managed objects of the protocol. Allnetwork access to the LMEs and their objects is provided by the networkmanagement agent 880.

The NMIB 895 contains the NMIBs 320 in the system and network managementvirtual field device (VFD) 310. The NMIB also contains objects used todefine configuration management, performance management and faultmanagement. The objects are accessed by network managers using fieldbusmessage specifications services. The objects used for network managementobjects are designed similar to the function blocks described earlier.

Flexible Function Blocks

For simplicity and illustrative purposes, flexible function blocks(“FFBs”) are described by referring mainly to exemplary embodiments.However, it is to be appreciated that FFBs and safety-related FFBs(“SIS-FFBs”) may be used in other implementations and designs usingother distributed control architectures. Further, it is to beappreciated that that principles discussed herein as applying to FFBsand/or SIS-FFBs may also be applicable to other block-orientedimplementations, fieldbus Architectures or other process controlsystems.

Function Block Framework

With reference to FIGS. 8A and 8B, the open system described aboveprovides a framework for and a detailed description of function blocks530/530′. With reference to FIG. 11, the open system described aboveprovides a framework for and description of the interconnection offunction block inputs and outputs to provide an application solution.

With reference to FIG. 12, described above are device descriptions (DD)860 which may be utilized to describe the input and output parameters ofa function block. The DD 860 provides information needed for a controlsystem to interpret the meaning of the function block data, includingthe human interface functions, such as calibration and diagnostics. Asstated above, the device description can be written in any standardizedprogramming language, such as C, C<, or SmallTalk, or a custom designeddevice description language.

Flexible Function Block—End User Configured Input/Output andAlgorithm/Program

As shown in FIG. 13, one implementation of an SIS-FFB 1350 may includeend-user configurable SIS-FFB input(s) 1351, end user configurableSIS-FFB output(s) 1352 and an end user configurable SIS-FFB algorithm(program) 1353. The end-user 1300 creates the SIS-FFB 1350, configuringthe input(s) 1351, output(s) 1352 and algorithm 1353 according to theneeds of a particular application and according to particular safetyrequirements. As described above for an SISFB, the SIS-FFB inputparameter(s) 1351 define the input(s) that are received by the SIS-FFB1350 and the SIS-FFB output parameter(s) 1352 define the output(s) thatare generated by the SIS-FFB 1350 after the input(s) are processed by analgorithm 1353, as specified by the SIS-FFB 1350. The SIS-FFBConfiguration Tool 1301 creates an SIS-FFB device description (DD) 1360that matches the SIS-FFB 1350 configured by the end-user. The SIS-FFBConfiguration Tool 1301 preferably creates the SIS-FFB 1350 bygenerating data files and code files that define the SIS-FFB 1350 basedon the user-configured input(s) 1351, output(s) 1352 and algorithm 1353and by generating a matching device description. Alternatively, theend-user 1300 (or a programmer) may generate the data and code filesthat define the SIS-FFB 1350 and the matching device description.

The end-user creates SIS-FFB 1350 and a matching SIS-FFB DD 860 byrunning SIS-FFB Configuration Tool 1301. SIS-FFB DD 860 enables humaninterface applications such as operator interface, tuning, calibrationand diagnostics to be used with SIS-FFB 1350.

Since the SIS-FFB 1350 operates in a function block framework, theend-user configured SIS-FFB inputs and outputs can be interconnected tosolve complex application-specific control problems such asdiscrete/hybrid/batch and PLC control. Any combination of blocks(standardized and flexible, SIS and non-SIS) may generally be used tosolve any particular application problem. It is also apparent thatinterconnection of standardized and flexible blocks applies to highspeed connections, such as HSE, and lesser speed connections. As suchFFBs and/or SIS-FFBs are generally communications protocol andconfiguration independent and may operate on any variety ofcommunications channels.

With reference to FIG. 14, two field devices 620 on a bus 120′controlling a process are illustrated. As shown, there are twoapplications, Application A and Application B, being run by the twofield devices 620. The first application, Application A, is anon-distributed application run by the first of the field devices 620.Application A is built by a combination of interconnected SISFB andSIS-FFBs (e.g., SIS-FFB 1350). The second application, Application B, isa distributed application run by both of the field devices 620.Application B is also built by a combination of interconnected SISFBsand SIS-FFBs (e.g., SIS-FFB 1350). As illustrated by FIG. 14, theSIS-FFB overcomes the limitation of non end-user configurableinput/output and non end-user configurable of standardized functionblocks. Distributed and non-distributed applications 1360 in fielddevices 620 on bus 120 can built using any combination of SISFBs andSIS-FFBs 1350. It is to be appreciated that in certain embodiments,significant reductions in plant control system installation, operatingand maintenance costs may be achieved using FFBs and/or SIS-FFBs.

FIG. 15 is a block diagram illustrating an example of a complexapplication built using a combination of standardized function blocksand FFBs. FIG. 15 is an example of multivariable matrix control for agas processing plant implemented using FFB-MVMC 954. The fielddevices/components (e.g., PI 1, TI 1, TI 2, TI-3, AI 1, AI 2, FIC 1, FIC2, LIC 1) shown in FIG. 15 preferably include standard function blocks.It is to be appreciated, while not shown in FIG. 15, that SISFBs and/orSIS-FFBs may be utilized in such an implementation as particular safetyrelated needs may require.

Extended Safety-Related Protocol (“SISRP”)

As discussed above, the various embodiments of the present inventionutilize an SISRP to authenticate and ensure that communications betweenSISCs have not been corrupted. In one embodiment, the SISRP utilizessequence numbers and CKs to validate or authenticate messages.

Publisher-Subscriber Communications

When publisher-subscriber communications are being accomplished, atleast one of the various embodiments facilitate secure communications bythe process shown in FIG. 16. However, before describing the illustratedembodiment in detail it is to be appreciated that, in general, a CK isassociated with each link between SISFBs and/or SIS-FFBs. As discussedabove, these CKs are generated by the configuration system and aredesirably stored in the resource as part of the publisher-subscriberlinkage objects. When data is to be published to a subscriber, desirablythe communications include the output parameters (i.e., the data),including value and status information, a sequence number (as describedabove) and an authenticators (for example, a CRC-32). One embodiment ofa process for generating the authenticator is shown in FIG. 16A.

As shown in FIG. 16A, the process for generating an authenticator forone embodiment of the present invention includes obtaining theinformation utilized to generate the authenticator (Operation 1602).This operation includes identifying the publisher and the subscriber soas to specify the connection over which the data is to be communicated(Operation 1604). This operation also entails obtaining the data(Operation 1606), obtaining the next sequence number used over theidentified connection (Operation 1608), obtaining the CK associated withthe specified connection (Operation 1610), and obtaining the objectindex used to identify the parameter in an FBAP to which the data to becommunicated pertains (Operation 1612). In one embodiment, theconnection key includes four (4) bytes of information, the sequencenumber includes two (2) bytes, the object index includes two (2) bytesand the data includes anywhere from two (2) to one hundred and twenty(120) bytes of information. Yet, it is to be appreciated that in otherembodiments of the present invention, other lengths for data and/orinformation may be utilized.

Once the desired and necessary information is obtained and suitablystored (e.g., in RAM or otherwise) for use by the processor in thepublishing device, the process continues with arranging the obtainedinformation into a desired sequence used to generate a Virtual ProtocolData Unit (“VPDU”), which may be subsequently used to generate theauthenticator. As shown in Operation 1614, one sequence that may beutilized to generate a VPDU is shown. It is to be appreciated that othersequences may be utilized, as particular implementations require orspecify. Commonly, however, the sequence utilized to arrange theinformation and generate the VPDU should be standardized so that anySISC (e.g., an SISFB or SIS-FFB) may authenticate data received from orprovided to any other SISFB/SIS-FFB. Thus, the sequence shown in FIG. 16is a preferred, but not mandatory, VPDU sequence. It is to beappreciated that this sequence is “virtual” because it is notcommunicated over the black channel to the subscribing device/component.

Using the sequence of information generated in Operation 1614, theprocess continues with generating the authenticator (“GA”) (Operation1616). It is to be appreciated that any of many well known authenticatorgeneration processes may be utilized. Desirably, an authenticator chosencomplies with SIL-3 and/or SIL-2 safety requirements. In one embodiment,CRC-32 algorithms are utilized to generate a CRC-32 authenticator. Inother embodiments, CRC-64 or other algorithms may be utilized togenerate the authenticator.

Referring now to FIG. 16B, the process shown in FIG. 16A continues withgenerating or assembling the Actual PDU (“APDU”), i.e., the packet ofdata and information that is to be communicated over the black channelfrom the publisher to the subscriber (Operation 1618). As shown in FIG.16B, the APDU is assembled, for one embodiment, in the followingsequence: the data 1606, the sequence number 1608 and the authenticator(GA) 1620 (i.e., the result generated in Operation 1616). It is to beappreciated, that other sequences may be utilized in other embodimentsof the present invention. However, for purposes of standardizedcommunications on an open fieldbus Architecture or similar architecture,it is desirable for all APDUs to utilize the same packet sequences. TheAPDU is then communicated over the black channel to the subscriber(Operation 1622).

Upon receiving the APDU, the subscriber suitably extracts and stores thereceived authenticator (“RA”) 1620′. It is to be appreciated that the GA1620, as well as the data 1606 and/or sequence number 1608 may becorrupted during transmission over the black channel. The subscriberthen proceeds with authenticating the received or actual protocol dataunit (“APDU”) and determines whether the data in the APDU has beencorrupted or is otherwise erroneous due to any of the before mentionedsafety considerations (e.g., retransmissions, omissions, bit falsifying,masquerading, and the like). In one embodiment of the present invention,APDU authentication proceeds in the subscriber by generating an expectedprotocol data unit (“EPDU”) (Operation 1623). As shown, to generate theEPDU, the subscriber arranges expected information and received data andinformation into the same sequence as was used in Operation 1614 togenerate the VPDU. More specifically, the subscriber obtains, from itsmemory or otherwise, an expected connection key 1624 and an expectedobject index 1626. These are combined, as shown, with the receivedsequence number 1608′ and the received data 1606′. In Operation 1628,the subscriber than calculates the expected authenticator value (“EA”)using, preferably, the same algorithms (e.g., CRC-32) as were utilizedby the publisher (in Operation 1616 to generate the GA (1620).

Referring now to FIG. 16C, in operation 1630, the EA is then compared tothe RA.

If the EA is not the same as the RA, then the data was somehow corruptedduring transmission over the black channel, was sent erroneously by thepublisher, or processed erroneously by the subscriber. The APDU isrejected by the subscriber and processing of the APDU is stopped(Operation 1632). Further, if a successive number of authenticatorverifications fails more than a threshold maximum number of times, thenthe link between the publisher and subscriber is desirably identified as“bad” and future PDUs are not processed using the “bad”publisher-subscriber link until the “bad” condition is resolved.

Referring again to Operation 1630, if the EA is the same as the RA, thenthe data and information communicated in the APDU is considered to beauthenticated. However, since it is possible for data to be sent from apublisher, without corruption over the black channel, in an incorrectsequence, desirably, the process continues with the subscriber verifyingthat the data received from the publisher is in the expected and correctsequence. This sequence verification is accomplished, for one embodimentof the present invention, by the subscriber obtaining the expectedsequence number from its VCR (Operation 1634) and comparing the receivedsequence number (“RSN”) to the expected sequence number (“ESN”)(Operation 1636). If the RSN is not equal to the ESN, then processing ofthe APDU stops (Operation 1632) and the data is discarded. If thesequence numbers are the same, then message/data processing continuesusing routine non-SIS message processing routines and procedures.Additionally, the subscriber sets a parameter, the last receivedsequence number (“LRSN”) variable, equal to the RSN and desirably resetsa “stalecount” parameter to a value of zero.

As mentioned previously, if sequence numbers are incorrect a givennumber of times (i.e., a “stalecount” exceeds a preset threshold), thenthe status of the connection between the associated publisher andsubscriber is set to “bad” and no future PDUs between the publisher andthe subscriber will be accepted until the connection status is reset. Inorder to recover or restore a “bad” connection between a publisher and asubscriber due to an exceeding of the “stalecount” threshold, for oneembodiment of the present invention, the process continues, commonlyafter a pause and manual or automatic resetting of the link, when avalid authenticator is received. Since the sequence number sent by thepublisher, the RSN, and the LRSN in the subscriber are most likelydifferent, the difference between the RSN and the LRSN is calculated. Ifthis difference exceeds the threshold for the stalecount, then the LRSNis set to the RSN, the stalecount is set to zero (0) and the PDU isdiscarded. The next PDU received is again processed according to theprocedures described in FIGS. 16A-C and normal data processing resumesprovided the authenticator and sequence numbers are less than thestalecount threshold.

While the operations shown in FIGS. 16A-16C set forth one embodiment forauthenticating data communicated over a black channel meets certainsafety requirements, it is to be appreciated that the operations, datasequences, authentication algorithms and the like may be changed, addedto and/or deleted. For example, in one embodiment, Operations 1630-1636may be deleted from the processing. Such Operations may be considered tobe optional if the RSN utilized to generate the EPDU in Operation 1623is replaced with an ESN. Using such a process flow, it is anticipatedthat the EA would not equal the RA if any of the bits in the receivedinformation were corrupted or otherwise erroneous. However, such aprocess flow may not be capable of more precisely identifying whichtypes of errors are occurring over the black channel, for example,whether the error due to sequence number problems, corruption of theactual data received, connection key problems or otherwise. As such itis to be appreciated that various process flows, algorithms, operations,PDUs and the like may be utilized to authenticate data communicatedbetween a publisher and a subscriber over a black channel.

Further, it is to be appreciated that by authenticating datacommunicated over the black channel for use by safety relatedcomponents, the various embodiments of the invention described hereinmay also be utilized to verify the operational status of a black channelfor non safety related devices. In particular, if repeated errors occurover a black channel between safety related devices, the probability oferrors for non-safety related devices occurring is probably increased.As such, by monitoring the rate and number of authentication failuresfor safety related communications, one may also indirectly monitor theoverall status of the black channel for all communications.

Client-Server Communications

In addition to supporting publisher-subscriber communications, thevarious embodiments of the present invention also support client-servercommunications between SISCs. As is commonly appreciated, client-servercommunications commonly involve read operations and write operations.The various embodiments of the present invention provides processes anddevices for implementing safety-related read and write processes.

Read

In general, a read is utilized in at least one embodiment of the presentinvention to read data utilized in an SIS device (i.e., one with SISCs)is similar, and in certain embodiments identical, to the requestsutilized in non-SIS devices (i.e., those without SISCs).

As shown in FIG. 17A, the process by which a component responds to aread request commonly begins with a response by the server (i.e., thecomponent providing the requested information to the requestor/client)of a request to obtain or “read” certain blocks (i.e., output values)provided by the device. Such blocks are commonly identified by an indexnumber or other identifier (Operation 1702). As is commonly appreciated,a device may be capable of outputting many blocks, some of which may beSISCs. As such, the process suitably continues with determining whetherthe read involves a safety related block (Operation 1704).

If the read does not involve an SISC, then processing desirablycontinues using standards non-SISRPs (Operation 1706).

Referring again to Operation 1704, if the read involves an SISC, forexample, one which includes a safety parameter such as SIS_Access or thelike, then processing continues using the SISRP. As discussed previouslywith respect to publisher-subscriber communications, the SISRP, in atleast one embodiment, provides for the calculation and transmission ofan authenticator over a black channel. In client-server communications,which involve SISCs, an authenticator is used in transmitting thedesired information. As shown in Operations 1708-1744 (FIGS. 17A-C), theprocess for generating an authenticator, transmitting the requested readdata, and authenticating the transmitted data is substantially the sameas that used in transmitting data for publisher-subscribercommunications. However, an optional and additional sub-index 1717 maybe included in the information utilized to generate and verify theauthenticator. Further, if the received sequence number is not equal tothe expected sequence number, then for at least one embodiment of thepresent invention, then the PDU is discarded.

Write

When write processes are desired for SISCs, desirably the SISRP, asdiscussed above, is utilized. To ensure that the receiver of the “write”data and information first verifies the received data and information,the SISRP includes an authenticator and sequence number in anycommunications. This process is accomplished in one embodiment of thepresent invention by comparing the length of the data to be written (asspecified, for example, in the FMS) against the length of the actuallyreceived data string. If such data string does not have a valid length,the data string is discarded. If the data strength has a valid length,then the authenticator is validated, preferably using the processespreviously discussed above with respect to publisher-subscribercommunications. Further, once the authenticator is validated, the writeoperation then proceeds. However, if the resource block associated withthe block receiving the write request (i.e., the server) is not in anOSS state or a Manual state, then desirably the write request isdiscarded. It is to be appreciated that it is generally undesirable towrite to parameters utilized by SISCs when a safety related resource isbeing utilized.

Additionally, under certain conditions, it may be desirable to writedata into an SISLO. Since sequence numbers are not provided for SISLOs,the write to an SISLO suitably proceeds with calculating anauthenticator without including a sequence number. Otherwise, processingof “writes” for SISLOs proceeds as discussed hereinabove for SISCs.

Additional Safety Features Authenticator Error Detection

In addition to the use of the SISRP and the other features and functionsdiscussed hereinabove, various embodiments of the present invention mayalso provide for authenticator error detection. Specifically, componentsimplementing the present invention may be configured to monitor thenumber of authenticator errors that are generated over a period of time.For components used in SIL-3 applications, desirably an error rategreater than one (1) in every 140 minutes results in the component beingconfigured in a fail-safe state with respect to its output blocks.Similarly, in an SIL-2 application, a threshold of one (1) error inevery fourteen (14) minutes results in configuring the component infail-safe state. Last, for SIL-1 applications, the error threshold isdesirably one (1) every 1.4 minutes. Other error rates may be utilizedfor other safety implementations, as desired.

Diagnostics Transducer Block

Various embodiments of the present invention may also be configured toinclude one or more diagnostic transducer blocks, when implement in afunction block fieldbus Architecture or similar architecture. However,commonly only one diagnostic transducer block exists per SIS device. Thediagnostic transducer block generally includes a timer and set ofcounter tracks which monitor all communications to/from the device(i.e., VCRs) for errors. Counters may include those for: badauthenticators, the time at which the last bad authenticator wasreceived, the number of bad sequence numbers, the time at which the lastbad sequence number was received, and the time since the last error wascommunicated through the black channel.

Black Channel Integrity Monitor

Various embodiments of the present invention may also include a blackchannel integrity monitor. This monitor verifies that the rate ofundetected errors (i.e., errors which are not detected by black channelmonitoring devices but are detected due to bad sequence numbers orinvalid authenticators) from the black channel does not exceed a givenlimit (either predetermine or set real-time). If the number of errorsexceed the threshold, desirably, this monitor terminates black channelconnections on which the errors are arising. Desirably, such connectionsare reinitiated upon operator intervention, reconnects and restarts.

However, various embodiments of the present invention may provide forautomated or semi-automate reconnects and restarts as particularimplementations desire.

Queuing Delay Monitoring and Detection

Additionally, certain embodiments of the present invention may alsoinclude a sequence number monitoring feature. Desirably, for apublisher-subscriber connection, a message is published with eachmacro-cycle. To aid in the detection of the queuing delays, at the startof the publisher-subscriber connection, the publisher communicates asequence number to the subscriber for the connection. Then thesubscriber increments the sequence number locally with each macro-cycleand compares it to the received sequence number, if the differenceexceeds the max tolerable variance, then fail-safe or other appropriateactions may be triggered by the subscriber or otherwise.

As discussed hereinabove, the various embodiments of the presentinvention provide for systems and processes for communicating dataamongst SIS devices providing one or more SISC using a fieldbusArchitecture and similar architectures and systems. While the presentinvention has been discussed with reference to certain architectures,functional blocks, processes, data structures and the like it is to beappreciated that the present invention is not so limited and is to beconstrued in accordance with the spirit and scope of the presentinvention, as set forth hereinabove, and/or as presently claimed hereinor claimed at a later time.

1. An apparatus for operating in a block-oriented safety related opencontrol system comprising: a memory, which includes at least one safetyrelated component; a processor, operably connected to the memory,wherein the processor executes the safety related component based on asystem schedule; and a medium attachment unit, which translates inputmessages and output messages between the processor and a transmissionmedium using an extended safety-related protocol.